What design patterns can be applied to the problem of configuration settings?

Question

In large and complex software products, managing custom settings is becoming a major pain. Two approaches that I saw to the problem:

• each component of the system loads its own configuration from configuration files or registry settings.
• has a settings loader class that loads all customizable system settings and each component requests a settings loader for its settings.

These approaches seem wrong to me.

Are there any design patterns that can be used to simplify the problem? Perhaps something that will use dependency injection technology.

Answer 1

I prefer to create an interface for setting the request, loading and saving. Using dependency injection, I can insert this into every component that requires it.

This provides flexibility in terms of replacing the configuration strategy and provides a common basis for work. I prefer this to the one global “settings loader” (your option 2), especially since I can override the configuration mechanism for one component if I absolutely need it.

Answer 2

I am currently working on a system in which a configuration is controlled by a single global singleton object that stores a configuration key map for values. In general, I would like this to not be done this way, because it can cause concurrency bottlenecks in the system and is careless for unit testing, etc.

I think Reed Copsi has a right to it (I voted for him), but I would definitely recommend reading Martin Fowler's article on dependency injection:

http://martinfowler.com/articles/injection.html

A small addition too ... if you want to do unit testing like a mock object, dependency injection is definitely the way to go.

Answer 3

How about this one. You define the Configurable interface using the single configure (configuration) method. A configuration argument is simply a hash table that associates the names of configuration parameters with their values.

Root objects can create a hash table of a configuration in any way (for example: reading from a configuration file). This hash table may contain configuration parameters for the iselft root object plus any parameter that one of its components, subcomponents, sub-subcomponents (etc.) can use.

The root object then calls configure for all of its custom components.

Answer 4

You can create several implementations of the interface that the configuration loader defines. Basically a strategy template in which you can define one basic interface as configLoader, and then use various implementations such as FileSystemLoader, ClasspathLoader, EnvVariablesLoader, etc. Details on this link