RSS Feed

The Design of Software (CLOSED)

Hello,

Does anybody know of a C/C++ design pattern for application/device configuration files? Or prehaps have a prefered way to achieve this. I'm wondering if it's possible to avoid the configuration module from having knowledge of all the modules it is providing configuration to?

Any direction appreciated,

Thanks,

Please explain what you're trying to do in a little more detail...

Of course it's "possible" to prevent the configuration system from knowing what modules use the configuration values:

The configuration system reads in a configuration file and converts it to a searchable internal representation (such as name-value pairs, ala old-style Window's INI files). The configuration system also publishes an API that allows client code to query the internal representation based on the searchable elements (e.g. names of the name-value pairs). Client modules then call the published API for the values that they need.

The configuration system only knows about the configuration file and its contents. The client modules only know about the names of the configuration values. The API keeps things cleanly separated so that you can rearrange the client modules or the configuration system independantly (you could replace the INI file with a database, for example).

Is there some subtlty to this question that I am missing, or is it really as painfully obvious as it appears?

No it's fairly basic stuff I suppose. I just didn't want to re-ivent the wheel if there are some really good examples out there. Ideal things are

1.) Registering of update functions. So for example the module will monitor changes to configuration parameters and issue calls to modules that requring updating when parameters chage.

2.) Can serialise all parameters for writing to files / other I/O .

I've started on this but it seems like something that was probably done and dusted a while ago.

Thanks

In C#, I just expose static properties for each of the configuration values, and a event for users to monitor for changes (external change is made to the configuration, my class detects that, and raises an event to let users know they need to reload their values)

IMO, simple is good.

I'm not sure the configuration file paradigm is a good solution to problem #1: registering of update functions.

Let's say an environment variable changes and the configuration system recognizes that value and broadcasts it to the client modules. Most of the modules happily accept the change and continue computing along. Module X however "asserts" the variable, determines that it's inappropriate, and falls back to the default or prior value. At this point, you essentially have another design problem to solve.

I'm not really qualified to say what's the best way of solving this type of problem, but I'm inclined to think you'd want a true, somewhat tightly coupled monitoring object that checks for changes to the environment, no different than one that checks to see if a button has been pressed. "Configuration systems" are really meant to provide a program with the necessary info needed to start itself.