Question

从这里开始：http://www.codingwithoutcomments.com/

如果您使用单身人士，请尝试使用依赖注入而不是从构造函数中调用getInstance（），使用：

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

而不是：

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

至少，使用依赖注入允许您通过遵循良好的封装原则来对类进行一些单元测试。

这种“依赖注入”如何？依赖注入是什么意思？
这不是打败了Singleton模式的目的吗？

这应该使用一段时间后再删除吗？

Answer 1

这是如何“依赖注入”？

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

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

依赖注入的主要优点是依赖可以在抽象接口上;没有必要将您的类绑定到特定的具体类或该类的特定实例。这使得测试更加方便 - 您的类可以独立测试，与它所依赖的任何接口的“存根”实现交互。它还可以更容易地跟踪依赖关系，因为它们都在代码中明确说明。

使用全局变量的主要优点是它们允许您编写略少的代码，并且您不必担心在它们成为问题之前管理依赖项;当他们这样做时，你可以简单地放弃该项目并开始一个新项目。

这不会破坏Singleton模式的目的吗？

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

这应该使用一段时间后再删除吗？

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

Answer 2

您提供的代码没有差异，并且它不是依赖注入，因为您将按值传递给构造函数（这是一个构造函数，对吧？）。

如果必须使用单例，则使用引用将它管理的对象传递给构造函数：

struct Abase
{
};
struct A : Abase // object of this type is created in the singleton
{
};

struct B
{
  B(Abase &a_) : a(a_)
  {
  }

private:
  Abase & a;
};

//...
B b( Singleton.getInstance() );
//...

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

2 个答案: