哪些设计模式可以应用于配置设置问题？
在大型且复杂的软件产品中，管理可配置设置成为一个主要难题。我见过的解决该问题的两种方法是：
- 让系统中的每个组件从配置文件或注册表设置加载自己的配置。
- 有一个设置加载器类，用于加载所有可配置的系统设置，并使每个组件查询设置加载器以获取其设置。
我觉得这些方法都是错误的。
是否有任何设计模式可以用来简化问题？也许可以利用依赖注入技术。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我更喜欢创建一个用于设置查询、加载和保存的界面。通过使用依赖注入，我可以将其注入到需要它的每个组件中。
这使得替换配置策略具有灵活性，并为所有工作提供了一个共同的基础。与单个全局“设置加载器”（您的选项 2）相比，我更喜欢它，特别是因为如果我绝对需要这样做，我可以覆盖单个组件的配置机制。
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.
我目前正在开发一个系统，其中配置由一个全局单例对象管理，该对象保留配置键到值的映射。一般来说，我希望不要这样做，因为它会导致系统中的并发瓶颈，并且单元测试很草率等。
我认为 Reed Copsey 有权利这样做（我投票给了他），但我会绝对推荐阅读 Martin Fowler 关于依赖注入的精彩文章：
http://martinfowler.com/articles/injection.html< /a>
还有一个小补充...如果您想做任何模拟对象类型单元测试，依赖注入绝对是正确的选择。
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.
这个怎么样。您可以使用单个方法configure(configuration) 定义一个可配置接口。配置参数只是一个哈希表，它将配置参数的名称与其值关联起来。
根对象可以以任何他们想要的方式创建配置哈希表（例如：从配置文件中读取它）。该哈希表可以包含根对象本身的配置参数，加上其组件、子组件、子子组件（等）之一可能使用的任何参数。
然后根对象在其所有可配置组件上调用configure(configuration)。
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.
您可以创建定义配置加载器的接口的多个实现。基本上是策略模式，您可以将一个基本接口定义为 configLoader，然后进一步定义不同的实现，例如 FileSystemLoader、ClasspathLoader、EnvVariablesLoader 等。
详细信息请参见链接
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
我通常有读取用户设置的控制器（本地存储在键值对中，通过 UserSettings 类访问）。
每个控制器负责读取静态定义的用户设置。然后，他们将所需的依赖项注入到视图（例如主题、语言包）或其他控制器（例如持久性机制、序列化、策略）中。
用户设置的存储方式取决于平台（例如，用于 Web 的本地存储、用于桌面的 XML 文件）。
I usually have controllers that read user settings (stored in key-value pairs locally, accessed via a
UserSettingsclass).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).