哪些设计模式可以应用于配置设置问题?

在大型和复杂的软件产品中,管理可配置设置成为一个主要的难题。我看到的解决这个问题的两种方法是:

  • 让系统中的每个组件从配置文件或注册表设置中加载自己的配置。
  • 具有一个设置加载程序类,该类加载所有可配置的系统设置,并让每个组件查询设置加载程序的设置。

我觉得这两种方法都不对。

有没有可以用来简化问题的设计模式?也许是利用依赖注入技术的东西。

46780 次浏览

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.

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.

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