Which design patterns can be applied to the configuration settings problem?

Question

In large and complex software products managing configurable settings becomes a major pain. Two approaches I've seen to the problem are:

• have each component in the system load its own configuration from config files or registry settings.
• have a settings loader class that loads all the configurable system settings and have each component query the settings loader for its settings.

These approaches both feel wrong to me.

Are there any design patterns that could be used to simplify the problem? Maybe something that would take advantage of the dependency injection technique.

Answer 1

I prefer to create an interface for setting query, loading, and saving. By using dependency injection, I can inject this into each component that requires it.

This allows flexibility in terms of replacing the configuration strategy, and gives a common base for everything to work from. I prefer this to a single, global "settings loader" (your option 2), especially since I can override the configuration mechanism for a single component if I absolutely need to do so.

Answer 2

I currently work on a system where the configuration is managed by one global singleton object that keeps a map of configuration keys to values. In general, I wish it hadn't been done this way because it can cause concurrency bottlenecks in the system and it's sloppy for unit testing, etc.

I think Reed Copsey has the right of it (I voted him up), but I would definitely recommend reading Martin Fowler's great article on dependency injection:

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

A slight addendum too...if you want to do any mock object type unit testing, dependency injection is definitely the way to go.