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

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.

How about this. You define an interface Configurable with a single method configure(configuration). The configuration argument is simply a hashtable which associates the names of configuration parameters with their values.

Root objects can create a configuration hashtable in whatever way they want (ex: reading it from a config file). This hashtable may contain configuration parameters for the root object iselft, plus any parameter that one of its components, sub-components, sub-sub-components (etc) might use.

The root object then invokes configure(configuration) on all of its configurable components.

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.