I'm quite confuse. the requirements tell me the format and also includes them
in the database file.
I'm trying to figure out the best approach when starting the server between:
1. ignoring the metadata (just skip them straight to the data since
i have a pre-knowledge about the database structure.
2. verifying the metadata according to my knowledge to check if
there is a corruption.
3. act as i don't know anything and read the fields length & name
from the metadata and then i can construct arrays that will be
sent to the room class that already knows the structure (quite
a paradox here)
the options are going from the less caring about future adding
to the most expendable. (and a bit more complicated.
of course the room class would need to change, I'm talking
now from the server point of view)
to sum it up: does SUN really expect us to read the metadata??
Roel: this is not about the room class but the server class that
should be, i think, less data-specific..
Jonathan Elkharrat wrote:does SUN really expect us to read the metadata??
It's Oracle these days
What you do with the metadata is up to you. I read the metadata dynamically and I believe Roberto just used hard-coded constants. Just make your choice and document in choices.txt why you opted for that approach, and you'll be fine
Roel De Nijs wrote:I read the metadata dynamically and I believe Roberto just used hard-coded constants.
Exactly I created an interface called DBConstants and had the Data class implement it... but, if it was today, I'd read the metadata dinamically. It is never said that we have to create a flexible solution because the db file format may change, and our solution has to be prepared for this... but, the effort that it takes to create a code that reads metadata dinamically (in my opinion) is pretty much the same to create a code with constants.
Sean Keane wrote:Classes implement interfaces and follow the IS-A rule. To say a class implements an interface that is only full of constants makes no sense from a design point of view.
I totally agree, Sean. This is another reason why I wouldn't take this approach if I had to do it again. This idea of constants in an interface was applied a looooong time ago, so this is also old fashioned.
Another thing that can be done for is, an enum can be created to contain these metadata constants. Something like this: