This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I have a very simple question with regards to the best or favorable approach for handling system wide constants. Here is the scenario:
I have an application in which there are quite a few application wide constants defined. Some of these constants have also a meaning in the relational model. For example., it will be defined in a master table and will be referenced in one of the transaction table. My application logic or rather the domain would also require to process some logic based on these constants. Normally the approaches that I have implemented so far will consist of a static class that will hold these constants. But is there a better or alternate way to do this?
SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
You are absolutely right in what you understood from my post above.
I also do not want to populate the data object with the values from the database every time I need it. But instead, read it once and populate the static class with the values read from the database. This has been my approach so far. But is there an even more better way to do this?
Joined: Apr 16, 2008
In order to determine a "better" way or if this is the "best" way, further detailed analysis of the application would be required.
Is there any significant problem with your current approach?
There are no significant problems. But in most of the projects that I worked, more or less the same pattern was followed. So just though of doing it in an alternate way and started exploring if some design patterns might be of help.
Joined: Apr 16, 2008
Ok. Just to clarify, storing data in a relational table and using this data to populate data members of an object is not an object-oriented design pattern. It is simply a "technique."
Object-oriented design patterns typically handle "commonly occurring problems" and are named and documented in accord with a prescribed format.