design-patterns - 依赖注入(inject)和单例设计模式

Question

我们如何确定何时使用依赖注入(inject)或单例模式。我在很多网站上读过，他们说“使用依赖注入(inject)而不是单例模式”。但我不确定我是否完全同意他们的观点。对于我的中小型项目，我肯定会直接使用单例模式。

例如记录器。我可以使用Logger.GetInstance().Log(...) 但是，为什么我需要使用记录器的实例注入(inject)我创建的每个类？

Answer 1

单例就像共产主义:它们在纸面上听起来都很棒，但在实践中却会出现问题。

单例模式过分强调访问对象的便捷性。它完全避开了上下文，要求每个使用者都使用 AppDomain 范围内的对象，不为不同的实现留下任何选项。它将基础结构知识嵌入到您的类中(调用 GetInstance())，同时精确地添加零表达能力。它实际上削弱了你的表达能力，因为你不能改变一个类使用的实现而不改变所有类的实现。您根本无法添加一次性的功能。

此外，当 Foo 类依赖于 Logger.GetInstance() 时，Foo 会有效地向消费者隐藏其依赖关系。这意味着您无法完全理解 Foo 或自信地使用它，除非您阅读其源代码并发现它依赖于 Logger 的事实。如果您没有源代码，就会限制您理解和有效使用您所依赖的代码的程度。

使用静态属性/方法实现的单例模式只不过是围绕实现基础设施的一种 hack。它以多种方式限制您，同时与其他选择相比没有提供明显的好处。您可以随心所欲地使用它，但由于有可行的替代方案可以促进更好的设计，因此永远不建议这样做。