Properties files were initially introduced to store configuration. Then, they got extended to include localisation information.
Now, how about storing business logic in properties files ?
We are doing a project that involves supporting several mobile handsets. Keeping this criteria in mind, we evolved a design whereby the core functionality remains as is, and to support a new handset, we only have to write the handset specific logic in an abstract class implementation, and accomodate this class in the Handset factory.
All’s going well until the Project Manager thought that I should be able to support more handsets without any source code change !!! There certainly is some logic which is different between the handsets; so how do you take care of that ? eg: Handsets sort phone book contacts differently, based on case and length of the strings.
So now, the big plan is that we make a super set of all possible logics we can think of at this stage, and then by configuring the properties file, add a new handset with some settings.
However if, the new handset still has some new logic, I still have to do a “server-drop”; and test; and clear the QA criteria ….
At the end of the day, it does look like a challenging task. But I have a different question in my mind.
Is the properties file (or a config file in .Net) not a part of the source code ? Why is changing the properties file not that big an issue like changing some source code ? Just because it is outside the binary ?
And for the kind of logic that we are trying to accomodate within the properties file, shouldn’t it be considered unsafe that business logic can be altered so easily ?
