One question that I have long asked myself is in object oriented programming,how should data such as settings and properties be passed around in an object oriented manner?
For example, most programs have options, say you have an option to set the undo level. This must be obtained and then set to a new value. If these settings are saved in an xml file, that section of the application (the option dialog) still needs some kind of xml parser to load the data. In another scenario where you would instead have an object that represents getting and setting settings, each area that needs this would have global access to all settings and a pointer to it would need to be passed around.
In a scenario like Maya or 3DS Max where these use huge gui systems to set object properties, how is this done in a clean and OO manner? The widget, needs to be given the data from the 3D object, and needs to send information to this object. Should a dialog know anything about 3D objects? Probably not. So how is this usually done?
In another scenario, I might need to update a status bar when my frame gets a mousemove. Does that mean my frame should have a pointer to my status bar?
Any abstract examples or readings about this would be appreciated.
Thanks
In a previous job, we had several XML files for our various apps, and much of the configuration was similar, but varied depending on the environment and execution context. Much of this configuration was usernames and password for third party services. When a password would change, we’d have to scour through dozens of XML files and make the changes, then, re-deploy dozens of apps.
I migrated all of the XML configurations to objects using interfaces and a type hierarchy. The interfaces allowed me to code against a common configuration structure, and get compile time support as well as use dependency injection to resolve the run-time instances. The type hierarchy allowed me to define the non-changing configurations once, in a base class, and only override the actual values that differed.
This would be overkill, I think, for a small app, but was imperative in our case.