到目前为止，在我的所有项目中，我都使用单例模式来访问整个应用程序中的应用程序配置。最近我看到很多关于不使用单例模式的文章，因为这种模式不提高可测试性，而且它隐藏了组件依赖。我的问题是存储应用程序配置的最佳方式是什么，它可以在整个应用程序中轻松访问，而无需在整个应用程序中传递配置对象？
提前致谢
马杜
问问题
16753 次
6 回答
24
我认为应用程序配置是单例模式的一个很好的使用。我倾向于自己使用它来避免每次我想访问它时都必须重新读取配置，因为我喜欢让配置成为强类型（即，不必每次都转换非字符串值）。我通常在我的 Singleton 中构建一些后门方法以支持可测试性——即注入 XML 配置的能力，以便我可以在测试中设置它，以及销毁 Singleton 以便在需要时重新创建它的能力。通常这些是我通过反射访问的私有方法，因此它们对公共接口隐藏。
编辑我们生活和学习。虽然我认为应用程序配置是使用 Singleton 的少数几个地方之一，但我不再这样做了。Lazy<T>通常，现在，我将使用配置属性的静态支持字段创建接口和标准类实现。这使我能够为每个属性提供“初始化一次”行为，并具有更好的可测试性设计。
于 2008-12-17T04:19:11.707 回答
5
使用依赖注入将单个配置对象注入到任何需要它的类中。通过这种方式，您可以使用模拟配置进行测试或任何您想要的......您不会明确地出去并获得需要使用配置文件初始化的东西。使用依赖注入，您也不会传递对象。
于 2008-12-18T22:32:28.350 回答
1
对于这种特定情况，我将创建一个配置对象并将其传递给需要它的人。
由于它是配置，它应该只在应用程序的某些部分使用，不一定应该是无所不在的。
但是，如果您在使用它们时没有遇到任何问题，并且不想那么努力地对其进行测试，那么您应该像今天一样继续使用它们。
阅读关于为什么它们被认为是有害的讨论。我认为大多数问题出现在单身人士持有大量资源时。
对于应用程序配置，我认为保持原样是安全的。
于 2008-12-17T04:19:41.927 回答
0
单例模式似乎是要走的路。这是我写的一个对我很有效的Setting类。
于 2009-03-01T02:34:02.390 回答
0
如果任何组件依赖于可以在运行时更改的配置（例如小部件的主题支持），您需要提供一些回调或信号机制来通知更改的配置。这就是为什么在创建时仅将所需的参数传递给组件（如颜色）是不够的。您还需要从组件内部提供对配置的访问（将完整的配置传递给组件），或者创建一个组件工厂来存储对配置及其所有创建的组件的引用，以便最终应用更改。
前者有一个很大的缺点，它会使构造函数混乱或破坏界面，尽管它可能是原型设计最快的。如果您考虑“得墨忒耳定律”，这是一个很大的否定，因为它违反了封装。后者的优点是组件保持其特定的接口，组件只取它们需要的东西，并且作为奖励，为您提供了重构的中心位置（工厂）。从长远来看，代码维护可能会受益于工厂模式。
此外，即使工厂是单例，它也可能在比配置单例少得多的地方使用。
于 2020-04-18T12:18:00.643 回答
-1
于 2011-03-04T19:43:29.030 回答