单例模式与依赖注入的关系

Question

如果您确实使用单例，请尝试使用依赖注入而不是从构造函数调用 getInstance()，请使用以下命令：

public MyConstructor(Singleton singleton) 
{
     this.singleton = singleton; 
}

而不是这个：

public MyConstructor() 
{
     this.singleton = Singleton.getInstance(); 
}

至少，使用依赖注入可以通过遵守良好的封装原则对类进行一些单元测试。

这个“依赖注入”是怎么回事？依赖注入是什么意思？
这不是违背了单例模式的目的吗？

这是应该使用一段时间然后稍后删除吗？

Answer 1

这个“依赖注入”是怎么回事？

“依赖注入”意味着你明确地为一个对象提供了它所依赖的所有其他对象的引用；这就是第一个示例在传递对构造函数的引用时所做的。

另一种方法是隐式提供它所依赖的对象，使它们可以全局访问。这就是第二个例子所做的。

依赖注入的主要优点是依赖可以在一个抽象接口上；无需将您的类与特定的具体类或该类的特定实例联系起来。这使得测试更加方便——你的类可以被单独测试，与它所依赖的任何接口的“存根”实现交互。它还可以更轻松地跟踪依赖项，因为它们都在代码中明确说明。

使用全局变量的主要优点是它们允许您编写稍微少一些的代码，并且您无需担心管理依赖关系，直到它们成为问题；当他们这样做时，您可以简单地放弃该项目并开始一个新的项目。

这不是违背了单例模式的目的吗？

这更取决于您认为反模式的目的是什么。它确实消除了全局可访问实例的便利性；但是，假设 Singleton 类确实遵循反模式，您仍然可以保证您收到的对象是 One True Instance。

这是应该使用一段时间然后稍后删除吗？

一旦你需要做反模式阻止的事情（单元测试、多个实例、子类型、抽象接口等），单例应该被一个普通类替换，通过引用传递给它的依赖项。一旦存在依赖注入，几乎不需要删除它；一旦发现单身人士不符合您的要求，您只需将其放回原处。