CODEWITHSUNDEEP
design-patternsconfigurationconfiguration-filesapplication-settings
oz10
oz10

Reputation: 158544

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

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

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.

Upvotes: 91

Views: 53542

Answers (5)

Sebastian-Alexandru Sarbu
Sebastian-Alexandru Sarbu

Reputation: 1

I usually have controllers that read user settings (stored in key-value pairs locally, accessed via a UserSettings class). Each controller is responsible for reading the statically defined user settings. They then inject needed dependencies into views (e.g. themes, language packs) or into other controllers (e.g. persistence mechanisms, serialization, strategies). How the user settings are stored is platform dependent (e.g. local storage for web, XML files for desktop).

Upvotes: 0

H S Raju
H S Raju

Reputation: 410

You can create multiple implementation of an interface that defines the config loader. Basically strategy pattern where you can define one basic interface as configLoader and then further different implementations such as FileSystemLoader, ClasspathLoader, EnvVariablesLoader etc. Details at this link

Upvotes: 0

Alain Désilets
Alain Désilets

Reputation: 559

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.

Upvotes: 5

Brent Writes Code
Brent Writes Code

Reputation: 19623

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.

Upvotes: 22

Reed Copsey
Reed Copsey

Reputation: 564891

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.

Upvotes: 51

Related Questions