在我迄今为止的所有项目中，我使用单例模式在整个应用程序中访问应用程序配置。最近我看到很多文章都在讨论不使用单例模式，因为这种模式不会提升可测试性，也会隐藏Component依赖性。 我的问题是什么是存储应用程序配置的最佳方式，可以在整个应用程序中轻松访问，而无需在整个应用程序中传递配置对象？
先谢谢
Madhu
答案 0 :(得分：21)
我认为应用程序配置是Singleton模式的一个很好的用途。我倾向于自己使用它来防止每次我想要访问它时重新读取配置，并且因为我喜欢强配置配置（即，不必每次都转换非字符串值）。我通常在我的Singleton中构建一些后门方法来支持可测试性 - 即注入XML配置的能力，这样我就可以在我的测试中设置它，并且能够销毁Singleton，以便在需要时重新创建它。通常，这些是我通过反射访问的私有方法，以便它们从公共接口隐藏。
编辑我们生活和学习。虽然我认为应用程序配置是少数使用Singleton的地方之一，但我不再这样做了。通常，现在，我将使用配置属性的静态Lazy<T>支持字段创建接口和标准类实现。这允许我对每个属性进行“初始化一次”行为，并具有更好的可测试性设计。
答案 1 :(得分：6)
使用依赖注入将单个配置对象注入任何需要它的类。通过这种方式，您可以使用模拟配置进行测试或任何您想要的...您没有明确地出去并获得需要使用配置文件初始化的内容。使用依赖项注入时，您不会传递对象。
答案 2 :(得分：1)
对于这种特定情况，我会创建一个配置对象并将其传递给需要它的人。
由于它是配置，因此只应在应用程序的某些部分使用，而不一定应该是无所不在。
但是，如果您在使用它们时没有遇到任何问题，并且不想那么难以测试，那么您应该像往常一样坚持到今天为止。
阅读有关他们认为有害的原因的讨论。我认为，当单身人士持有大量资源时，大多数问题都会出现。
对于应用程序配置，我认为保持它是安全的。
答案 3 :(得分：0)
单身模式似乎是要走的路。这是我写的Setting class，对我来说效果很好。
答案 4 :(得分：0)
答案 5 :(得分：0)
如果任何组件依赖于可以在运行时更改的配置（例如，对小部件的主题支持），则需要提供一些回调或信令机制来通知已更改的配置。这就是为什么在创建时仅将所需的参数传递给组件是不够的（例如颜色）。 您还需要提供从组件内部对配置的访问（将完整的配置传递给组件），或者使组件工厂存储对配置及其所有已创建组件的引用，以便最终可以应用更改。
前者有一个很大的缺点，即它可能使构造函数混乱或破坏接口，尽管它可能是原型制作最快的方法。如果考虑“ Demeter法则”，这是一个很大的否定，因为它违反了封装。 后者的优点是组件保留其特定接口，使组件仅在需要的地方使用它们，而且，额外的好处是，您可以在中心位置进行重构（工厂）。从长远来看，代码维护可能会受益于工厂模式。
此外，即使工厂是单身人士，也可能会比配置单身人士在更少的地方使用它。