I don’t quite know how to ask this question, so I’ll phrase it as an example instead:
Imagine in an application you have a Country object. There are two properties of this object: Name, and a ‘Bordering Countries‘ collection. More properties might be added later, but it will be the kind of information that would change very rarely (e.g. changes of country names/borders)
Lets say this application needs to know about all of the countries in the world. Where would you store these object’s state? How would you new them up? It seems silly to store all this state in the DB, since it won’t change very often.
One option might be to have an abstract ‘country’ base object, and have a class for each country inheriting from this with the details of each country. But this doesn’t seem quite right to me.
What is the proper way of dealing with these kinds of objects?
UPDATES:
Someone asked about language: C#
Also, I’m coming at this from a web application perspective, so there wouldn’t be multiple client installations where I’d have to worry about updating hard coded values.
Most people have suggested not hardcoding the data, but using the DB or XML files to store the data. Could anyone provide an example of how this kind of object would be ‘newed up’ (from e.g. an XML file)? Would you use some kind of helper or factory method to obtain instance of a particular country?
You’ve got a variety of answers, so I thought I’d add my $0.02 worth.
Personally I alway hard code fixed lists like this (same with postcodes). That being said, when I’m at your position, I’ll always optimize for readability. ie What will make sense in 6 months time, when you’ve forgotten about this project and have to do some maintenance?
If I had to do it with a database:
Your unit test:
Oops! You probably want to populate the whole list (not one at a time!)
DB:
If I was hardcoding it: