什么是依赖注入？

依赖注入（DI）意味着分离彼此依赖的对象。假设对象A依赖于对象B，因此想法是将这些对象彼此分离。我们不需要使用new关键字对对象进行硬编码，而是在运行时共享对对象的依赖关系，而不管编译时间如何。如果我们谈论

依赖注入在Spring中的工作原理：

我们不需要使用new关键字硬编码对象，而是在配置文件中定义bean依赖关系。弹簧容器将负责连接所有部件。

控制反转（IOC）

IOC是一个通用概念，可以用多种不同的方式表达，依赖注入是IOC的一个具体例子。

两种类型的依赖注入：

构造器注入沉淀剂注入

1.基于构造函数的依赖注入：

当容器调用具有多个参数的类构造函数时，就完成了基于构造函数的DI，每个参数表示对其他类的依赖。

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2.基于Setter的依赖注入：

基于Setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean上的Setter方法来实现的。

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

注：对于强制依赖项使用构造函数参数，对于可选依赖项使用setter，这是一个很好的经验法则。注意，如果我们在setter上使用基于@Required的注释，则可以将setter作为必需的依赖项。

什么是依赖注入？

依赖注入（DI）意味着分离彼此依赖的对象。假设对象A依赖于对象B，因此想法是将这些对象彼此分离。我们不需要使用new关键字对对象进行硬编码，而是在运行时共享对对象的依赖关系，而不管编译时间如何。如果我们谈论

依赖注入在Spring中的工作原理：

我们不需要使用new关键字硬编码对象，而是在配置文件中定义bean依赖关系。弹簧容器将负责连接所有部件。

控制反转（IOC）

IOC是一个通用概念，可以用多种不同的方式表达，依赖注入是IOC的一个具体例子。

两种类型的依赖注入：

构造器注入沉淀剂注入

1.基于构造函数的依赖注入：

当容器调用具有多个参数的类构造函数时，就完成了基于构造函数的DI，每个参数表示对其他类的依赖。

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2.基于Setter的依赖注入：

基于Setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean上的Setter方法来实现的。

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

注：对于强制依赖项使用构造函数参数，对于可选依赖项使用setter，这是一个很好的经验法则。注意，如果我们在setter上使用基于@Required的注释，则可以将setter作为必需的依赖项。

流行的答案毫无用处，因为它们以一种无用的方式定义依赖注入。让我们同意，“依赖性”是指我们的对象X所需要的一些预先存在的其他对象。但当我们说

$foo = Foo->new($bar);

我们只调用将参数传递到构造函数中。自从构造器被发明以来，我们一直在定期这样做。

“依赖注入”被认为是“控制反转”的一种类型，这意味着某些逻辑被从调用者中取出。当调用者传入参数时，情况并非如此，因此如果是DI，DI就不会意味着控制反转。

DI意味着在调用者和构造函数之间有一个中间层来管理依赖关系。Makefile是依赖注入的一个简单示例。“调用者”是在命令行上键入“make bar”的人，“构造函数”是编译器。Makefile指定bar依赖于foo，并执行

gcc -c foo.cpp; gcc -c bar.cpp

在执行

gcc foo.o bar.o -o bar

键入“makebar”的人不需要知道bar依赖于foo。在“makebar”和gcc之间注入了依赖关系。

中间层的主要目的不仅仅是将依赖项传递给构造函数，而是在一个地方列出所有依赖项，并向编码器隐藏它们（而不是让编码器提供它们）。

通常，中间层为构造的对象提供工厂，这些对象必须提供每个请求的对象类型都必须满足的角色。这是因为通过拥有一个隐藏构建细节的中间层，您已经受到了工厂施加的抽象惩罚，所以您不妨使用工厂。

我们可以实现依赖注入来了解它：

class Injector {
  constructor() {
    this.dependencies = {};
    this.register = (key, value) => {
      this.dependencies[key] = value;
    };
  }
  resolve(...args) {
    let func = null;
    let deps = null;
    let scope = null;
    const self = this;
    if (typeof args[0] === 'string') {
      func = args[1];
      deps = args[0].replace(/ /g, '').split(',');
      scope = args[2] || {};
    } else {
      func = args[0];
      deps = func.toString().match(/^function\s*[^\(]*\(\s*([^\)]*)\)/m)[1].replace(/ /g, '').split(',');
      scope = args[1] || {};
    }
    return (...args) => {
      func.apply(scope || {}, deps.map(dep => self.dependencies[dep] && dep != '' ? self.dependencies[dep] : args.shift()));
    }
  }
}

injector = new Injector();

injector.register('module1', () => { console.log('hello') });
injector.register('module2', () => { console.log('world') });

var doSomething1 = injector.resolve(function (module1, module2, other) {
  module1();
  module2();
  console.log(other);
});
doSomething1("Other");

console.log('--------')

var doSomething2 = injector.resolve('module1,module2,', function (a, b, c) {
  a();
  b();
  console.log(c);
});
doSomething2("Other");

以上是javascript的实现

什么是依赖注入（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来投射这些是很好的。

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

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

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

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

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

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

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

.