Currently I am doing the same, but I also have the same concern.
I think at the end, from the Object Oriented Design point of view you would want to make the Room and Data class as loosely coupled as possible, so you can make the Room
class reusable if at a later day, you have to switch your Data class implementation from a Data File (where you are forced to deal and manipulate all the Schema details)
to a RDBMS (MySQL, Oracle, etc.).
In the Andrew Monkhouse book, in the DVD class the equivalent of the Hotel Room in URLyBird, all the fields length are declared as static final constants, even though
in the Denny's DVD example from the book you don't have to deal reading a Schema.
I think the catch in URLyBird is that the data file format has to be preserved because it is also used by a legacy application to generate reports.
I think it is OK to have all the static final constants declared, as long as you justify it in your choices.txt.
I read my database schema dynamically, so didn't use constants to declare field length etc. The only static I declared was the expected value of the magic cookie. My good buddy Roberto Perillo declared the necessary information in static final constants. We both justified in choices.txt and passed. So no need to worry, it is certainly a valid approach.
Cory Max wrote:the data structure describes itself, its a good idea to compare them.
If you read data structure to compare values, why not just read it dynamically and make your program more solid, because able to handle changes in data structure without any code modification (like a column getting bigger) and your Data class can also be used to handle a file with customers (having complete other data structure)?