什么是依赖注入（DI）？

正如其他人所说，依赖注入（DI）消除了直接创建和管理我们感兴趣的类（消费者类）所依赖的其他对象实例（在UML意义上）的生命周期的责任。这些实例通常作为构造函数参数或通过属性设置器传递给我们的消费者类（依赖对象实例化和传递给消费者类的管理通常由控制反转（IoC）容器执行，但这是另一个主题）。

DI、DIP和固体

具体来说，在Robert C Martin的面向对象设计的SOLID原则的范例中，DI是依赖反转原则（DIP）的可能实现之一。DIP是SOLID咒语的D——其他DIP实现包括服务定位器和插件模式。

DIP的目标是解耦类之间紧密、具体的依赖关系，相反，通过抽象来放松耦合，这可以通过接口、抽象类或纯虚拟类来实现，具体取决于所使用的语言和方法。

如果没有DIP，我们的代码（我称之为“消费类”）直接耦合到一个具体的依赖项，并且经常承担着知道如何获取和管理该依赖项实例的责任，即概念上：

"I need to create/use a Foo and invoke method `GetBar()`"

然而，在应用DIP后，这一要求被放宽，获得和管理Foo依赖寿命的担忧已经消除：

"I need to invoke something which offers `GetBar()`"

为什么使用DIP（和DI）？

以这种方式解耦类之间的依赖性允许用其他实现轻松替换这些依赖性类，这些实现也满足抽象的前提条件（例如，依赖性可以与同一接口的另一个实现切换）。此外，正如其他人所提到的，通过DIP解耦类的最常见原因可能是允许单独测试消费类，因为这些依赖关系现在可以被清除和/或嘲笑。

DI的一个结果是依赖对象实例的寿命管理不再由消费类控制，因为依赖对象现在被传递到消费类（通过构造函数或setter注入）。

这可以用不同的方式来看待：

如果需要保留消费类对依赖项的生命周期控制，则可以通过将用于创建依赖类实例的（抽象）工厂注入消费类来重新建立控制。消费者将能够根据需要通过工厂上的Create获取实例，并在完成后处理这些实例。或者，依赖实例的生命周期控制可以放弃给IoC容器（下面将详细介绍）。

何时使用DI？

在可能需要用依赖性替代等效实现的情况下，任何时候，如果您需要对类的方法进行单元测试，依赖项的生命周期的不确定性可能需要进行实验（例如，嘿，MyDepClass是线程安全的-如果我们将其设置为单例并将同一实例注入所有消费者，会怎么样？）

实例

这里是一个简单的C#实现。给定以下消费类：

public class MyLogger
{
   public void LogRecord(string somethingToLog)
   {
      Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
   }
}

虽然看似无害，但它对另外两个类System.DateTime和System.Console有两个静态依赖关系，这不仅限制了日志输出选项（如果没有人在监视，则日志记录到控制台将毫无价值），而且更糟糕的是，考虑到对非确定性系统时钟的依赖关系，很难自动测试。

然而，我们可以将DIP应用于这个类，方法是将时间戳问题抽象为依赖项，并将MyLogger仅耦合到一个简单的接口：

public interface IClock
{
    DateTime Now { get; }
}

我们还可以将对Console的依赖放宽为抽象，例如TextWriter。依赖注入通常实现为构造函数注入（将抽象作为参数传递给依赖项作为消费类的构造函数）或Setter注入（通过setXyz（）Setter或定义了{set；}的.Net Property传递依赖项）。构造函数注入是首选的，因为这样可以保证类在构造后处于正确的状态，并允许将内部依赖字段标记为只读（C#）或最终（Java）。因此，在上面的示例中使用构造函数注入，这就给我们留下了：

public class MyLogger : ILogger // Others will depend on our logger.
{
    private readonly TextWriter _output;
    private readonly IClock _clock;

    // Dependencies are injected through the constructor
    public MyLogger(TextWriter stream, IClock clock)
    {
        _output = stream;
        _clock = clock;
    }

    public void LogRecord(string somethingToLog)
    {
        // We can now use our dependencies through the abstraction 
        // and without knowledge of the lifespans of the dependencies
        _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
    }
}

（需要提供一个具体的Clock，它当然可以恢复到DateTime。现在，这两个依赖关系需要由IoC容器通过构造函数注入提供）

可以构建一个自动化的单元测试，这无疑证明了我们的记录器工作正常，因为我们现在可以控制依赖关系-时间，我们可以监视书面输出：

[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
    // Arrange
    var mockClock = new Mock<IClock>();
    mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
    var fakeConsole = new StringWriter();

    // Act
    new MyLogger(fakeConsole, mockClock.Object)
        .LogRecord("Foo");

    // Assert
    Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}

下一步

依赖注入总是与控制反转容器（IoC）相关联，以注入（提供）具体的依赖实例，并管理生命周期实例。在配置/引导过程中，IoC容器允许定义以下内容：

每个抽象和配置的具体实现之间的映射（例如“消费者请求IBar时，返回ConcreteBar实例”）可以为每个依赖项的生命周期管理设置策略，例如为每个消费者实例创建新对象，在所有消费者之间共享单一依赖项实例，仅在同一线程之间共享同一依赖项实例等。在.Net中，IoC容器了解IDisposable等协议，并将根据配置的生命周期管理来负责处理依赖关系。

通常，一旦IoC容器被配置/引导，它们就可以在后台无缝地运行，从而让编码器专注于手头的代码，而不用担心依赖性。

DI友好代码的关键是避免类的静态耦合，并且不要使用new（）创建依赖项

根据上面的示例，依赖关系的解耦确实需要一些设计工作，对于开发人员来说，需要进行范式转换，以打破直接添加依赖关系的习惯，转而信任容器来管理依赖关系。

但好处很多，特别是能够彻底测试你感兴趣的班级。

注意：POCO/POJO/Serialization DTO/Entity Graphs/Anonymous JSON投影等（即“仅数据”类或记录）的创建/映射/投影（通过新的..（））不被视为依赖项（在UML意义上），也不受DI的约束。使用new来投射这些是很好的。

来自Christoffer Noring，Pablo Deeleman的书《学习角度-第二版》：

“随着我们的应用程序的增长和发展，我们的每一个代码实体都将在内部需要其他对象的实例，在软件工程领域中，这些对象被称为依赖关系。将这些依赖关系传递给依赖客户端的动作被称为注入，它还需要另一个代码主体（称为注入器）的参与。注入器将负责用于实例化和引导所需依赖项的功能，以便它们从成功注入客户端的那一刻起就可以使用。这一点非常重要，因为客户机不知道如何实例化自己的依赖关系，只知道为了使用它们而实现的接口。"

发件人：Anton Moiseev。《字体角度发展，第二版》一书：

“简而言之，DI帮助您以松散耦合的方式编写代码，并使代码更易于测试和重用。”

针对5岁儿童的依赖注入。

当你自己去把冰箱里的东西拿出来时，你可能会引起问题。你可能会让门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。你甚至可能在寻找我们甚至没有或已经过期的东西。

你应该做的是陈述一个需要，“我需要午餐时喝点东西”，然后我们会确保你坐下吃饭时有东西。

在进行技术描述之前，首先用一个真实的例子来形象化它，因为你会发现很多技术知识需要学习依赖注入，但大多数人都无法理解它的核心概念。

在第一张图中，假设你有一家拥有很多单位的汽车工厂。汽车实际上是在装配单元中制造的，但它需要发动机、座椅和车轮。因此，装配单元依赖于这些所有单元，它们是工厂的依赖。

你可以感觉到，现在在这个工厂维护所有的任务太复杂了，因为除了主要任务（在组装单元组装汽车）外，你还必须关注其他单元。现在维护成本很高，而且厂房很大，因此需要额外的租金。

现在，看第二张图。如果你找到一些供应商公司，他们会以比你自己生产成本更低的价格为你提供车轮、座椅和发动机，那么现在你就不需要在工厂里生产了。您现在可以为您的装配单元租用一栋较小的建筑，这将减少您的维护任务，并降低额外的租赁成本。现在你也可以只专注于你的主要任务（汽车组装）。

现在我们可以说，组装汽车的所有依赖都是由供应商注入工厂的。这是一个真实的依赖注入（DI）示例。

现在用技术术语来说，依赖注入是一种技术，一个对象（或静态方法）提供另一个对象的依赖。因此，将创建对象的任务传递给其他人并直接使用依赖关系称为依赖注入。

这将帮助您现在通过技术说明学习DI。这将显示何时使用DI，何时不使用DI。

.

使依赖注入概念易于理解。让我们以开关按钮为例来切换（打开/关闭）灯泡。

无依赖注入

Switch需要事先知道我连接到哪个灯泡（硬编码依赖项）。所以

开关->永久灯泡//开关直接连接到永久灯泡，测试不容易

Switch(){
PermanentBulb = new Bulb();
PermanentBulb.Toggle();
}

使用依赖注入

开关只知道我需要打开/关闭传递给我的灯泡。所以，

开关->灯泡1或灯泡2或夜灯泡（注入依赖性）

Switch(AnyBulb){ //pass it whichever bulb you like
AnyBulb.Toggle();
}

修改开关和灯泡的James示例：

public class SwitchTest { 
  TestToggleBulb() { 
    MockBulb mockbulb = new MockBulb(); 

    // MockBulb is a subclass of Bulb, so we can 
    // "inject" it here: 
    Switch switch = new Switch(mockBulb); 

    switch.ToggleBulb(); 
    mockBulb.AssertToggleWasCalled(); 
  } 
}

public class Switch { 
  private Bulb myBulb; 

  public Switch() { 
    myBulb = new Bulb(); 
  } 

  public Switch(Bulb useThisBulbInstead) { 
    myBulb = useThisBulbInstead; 
  } 

  public void ToggleBulb() { 
    ... 
    myBulb.Toggle(); 
    ... 
  } 
}`

依赖注入意味着一种方式（实际上是任何方式），代码的一部分（例如类）可以以模块化的方式访问依赖项（代码的其他部分，例如它所依赖的其他类），而不必对它们进行硬编码（因此它们可以自由更改或重写，甚至可以根据需要在其他时间加载）

（顺便说一句，是的，对于一个相当简单的概念，它已经成为一个过度炒作的25美元的名字），我的25美分