Originally posted by Roy Mallard:
I mean the field types (string, date, number etc.) are not given in the data file, so you need to get the type information from somewhere.
I currently hard-code the field types in a class, although I might change this to read the field types from a .properties file.
I believe the assignment specifically states what information is allowed in properties files and that doesn't include schema details. I'd suggest that by adopting such a strategy you run the risk of being marked down or failing.
I understand the purpose of what you are suggesting. The requirements state that we should strive for a flexible implementation and that, in turn, implies that the code which does the physical reading from the file should be generic i.e. independent of type and format.
I'm currently trying to introduce this concept into my implementation by injecting into the "file reader" a strategy or strategies which encapsulate the following information:
The relationship between record index and the offset from the start of the file of the specified record;The relationship between the record as a whole and it's individual fields, and the attributes of those fields (e.g. name, size, type). This approach gives me the flexibility to vary the behaviour of my file reader by injecting a strategy which contains hardcoded rules and values (possibly of use in early prototyping), or one which expects and reads the UrlyBird schema metadata (the final submission to the examinar), or one which reads a different schema format altogether (for use in some hypothetical future datafile format).
Unfortunately I've hit a mental brick wall whilst trying to iron out the aesthetics of my full implementation. I suspect that I'm too hung up on the style of my solution, but I can't help shaking the feeling that the examiners will mark on style (or design as they might call it).