跨Java系统的配置设计模式

问题是旧帽子-什么是一个适当的设计，以支持配置文件或系统配置在我们的系统？我已经确定了以下要求：

• 应该能够在不重新部署的情况下实时重新加载并立即拾取更改
• 对于依赖相同凭据（例如SQL或memcached凭据）的软件应用程序，即使应用程序位于不同位置的不同计算机上，也应该能够在一个单独的位置引入更改并一次性部署
• 支持运行同一应用程序的多个进程/计算机

而我正在努力解决的设计部分：

• 每个主要类是否应该将自己的“Config”类作为构造函数的输入参数？是否应该有一个工厂负责对正确的配置进行实例化？或者每个类都应该从自己的配置中读取并自动重新加载吗
• 如果类B派生自类A，或者由类A组成，那么继承配置文件是否有意义
• 假设类A由M1和M2（M表示“main”）构造，M1负责实例化资源。假设资源依赖于MySQL凭据，我希望M1和M2之间是通用的，那么有没有一种方法可以避免断开所有权和放入a的配置v之间的权衡。跨M1和M2的配置复制资源

这些都是我现在正在处理的设计问题，我并不真正了解在这里工作的设计模式或框架。我使用Java，因此任何解决此问题的库都是非常受欢迎的。

您可能需要查看它，它提供了广泛的功能。您可以指定多个配置源，并将它们排列成层次结构。一个特别令人感兴趣的特性是提供，允许您的组件注册它们对配置更改的兴趣

---

动态更改配置的目标很诱人，但需要对设计进行一些思考。您需要小心地管理这些更改（例如，如果缩小队列大小会发生什么情况-是否丢弃队列上的现有元素？

是否每个主要类都将其自己的“Config”类作为构造函数的输入参数？

不，这听起来像是一个糟糕的设计，它会不必要地使大量代码过于复杂。我建议您将全局配置类实现为一个单例。Singleton意味着只有一个配置对象，它是配置类的私有静态变量，可以在需要时使用公共静态getInstance（）方法获取

---

此配置对象应将所有配置参数存储为键/值对。

我宁愿注入一个类，而不是将其指定为单例。这将使目前为止的4个应用程序和20个内部库的测试变得更加容易？