什么是依赖注入？

a

ardila

到目前为止，我发现的最佳定义是 one by James Shore：

“依赖注入”是 5 美分概念的 25 美元术语。 [...] 依赖注入意味着给一个对象它的实例变量。 [...]。

依赖注入基本上是提供对象需要的对象（它的依赖项），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许模拟或删除依赖项。

可以通过多种方式（例如构造函数注入或 setter 注入）将依赖项注入到对象中。甚至可以使用专门的依赖注入框架（例如 Spring）来做到这一点，但它们当然不是必需的。您不需要这些框架来进行依赖注入。显式实例化和传递对象（依赖项）与框架注入一样好。

我喜欢 James 文章的解释，尤其是结尾：“不过，你必须惊叹于任何采用三个概念（'TripPlanner'、'CabAgency'和'AirlineAgency'）的方法，将它们变成九个以上的类，然后在编写一行应用程序逻辑之前添加数十行粘合代码和配置 XML。”这是我经常看到的（可悲）——依赖注入（正如他所解释的那样本身很好）被滥用来使本来可以更容易完成的事情变得过于复杂——最终编写“支持”代码......

回复：“显式实例化和传递对象（依赖项）与框架注入一样好。”。那么为什么人们制作框架这样做呢？

出于同样的原因，每个框架都被编写（或至少应该被编写）：因为一旦达到一定的复杂性，就需要编写大量重复的/样板代码。问题是很多时候人们会寻求一个框架，即使它不是严格需要的。

5 美分概念的 25 美元期限已过时。这是一篇对我有帮助的好文章：codeproject.com/Articles/615139/…

@dzieciou 也很高兴在您使用 DI 容器时为您构建对象图，并且能够在一个地方将一种实现换成另一种实现也很高兴。通常对于愚蠢、简单的东西，我可能会传入依赖项，但在大多数框架中使用 DI 容器非常容易，通常也很容易做到这一点。

T

Trieu Toan

依赖注入是将依赖传递给其他对象或框架（依赖注入器）。

依赖注入使测试更容易。注入可以通过构造函数完成。

SomeClass() 的构造函数如下：

public SomeClass() {
    myObject = Factory.getObject();
}

问题：如果myObject涉及磁盘访问或网络访问等复杂任务，则很难对SomeClass()进行单元测试。程序员必须模拟 myObject 并可能拦截工厂调用。

替代解决方案：

将 myObject 作为参数传递给构造函数

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

myObject 可以直接通过，使测试更容易。

一种常见的替代方法是定义一个不做任何事情的构造函数。依赖注入可以通过setter来完成。（h/t @MikeVella）。

Martin Fowler 记录了第三种选择（h/t @MarcDix），其中类显式地为程序员希望注入的依赖项实现接口。

在没有依赖注入的情况下，很难在单元测试中隔离组件。

2013 年，当我写这个答案时，这是 Google Testing Blog 的一个主要主题。这对我来说仍然是最大的优势，因为程序员在他们的运行时设计中并不总是需要额外的灵活性（例如，对于服务定位器或类似的模式）。程序员经常需要在测试期间隔离类。

承认 Ben Hoffstein 对 Martin Fowler 文章的引用是必要的，因为它指出了该主题的“必读”，我接受 wds 的回答，因为它实际上回答了这里的问题。

+1 用于解释和动机：创建一个类依赖于其他人的问题的对象。另一种说法是 DI 使类更具凝聚力（它们的责任更少）。

您说依赖项是“传递给构造函数”的，但据我了解，这并不完全正确。如果在实例化对象后将依赖项设置为属性，它仍然是依赖项注入，对吗？

@MikeVella 是的，这是正确的。在大多数情况下，它没有真正的区别，尽管属性通常更灵活一些。我将稍微编辑文本以指出这一点。

到目前为止我找到的最好的答案之一，因此我真的有兴趣改进它。它缺少对依赖注入的第三种形式的描述：Interface injection。

g

gtiwari333

我在 loose coupling 方面发现了这个有趣的例子：

来源：Understanding dependency injection

任何应用程序都由许多对象组成，这些对象相互协作以执行一些有用的事情。传统上，每个对象都负责获取自己对与之协作的依赖对象（依赖项）的引用。这导致了高度耦合的类和难以测试的代码。

例如，考虑一个 Car 对象。

Car 取决于车轮、发动机、燃料、电池等来运行。传统上，我们将此类依赖对象的品牌与 Car 对象的定义一起定义。

没有依赖注入（DI）：

class Car{
  private Wheel wh = new NepaliRubberWheel();
  private Battery bt = new ExcideBattery();

  //The rest
}

这里，Car 对象负责创建依赖对象。

如果我们想在最初的 NepaliRubberWheel() 穿孔之后更改其依赖对象的类型 - 比如 Wheel 怎么办？我们需要使用它的新依赖项重新创建 Car 对象，例如 ChineseRubberWheel()，但只有 Car 制造商可以这样做。

那么 Dependency Injection 为我们做了什么...？

使用依赖注入时，对象在运行时而不是编译时（汽车制造时）被赋予其依赖关系。这样我们现在可以随时更改 Wheel。在这里，dependency (wheel) 可以在运行时注入 Car。

使用依赖注入后：

在这里，我们在运行时注入依赖项（Wheel 和 Battery）。因此，术语：依赖注入。我们通常依靠 Spring、Guice、Weld 等 DI 框架来创建依赖项并在需要的地方注入。

class Car{
  private Wheel wh; // Inject an Instance of Wheel (dependency of car) at runtime
  private Battery bt; // Inject an Instance of Battery (dependency of car) at runtime
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}

优点是：

解耦对象的创建（换句话说，将使用与对象的创建分开）

能够替换依赖项（例如：Wheel、Battery）而不更改使用它的类（汽车）

提倡“代码接口而不是实现”原则

在测试期间创建和使用模拟依赖项的能力（如果我们想在测试期间使用车轮模拟而不是真实实例。我们可以创建模拟车轮对象并让 DI 框架注入到 Car）

我理解这一点的方式是，我们可以在需要时注入所述对象，从而消除第一个对象对它的依赖，而不是将新对象实例化为另一个对象的一部分。那正确吗？

我在此处以咖啡店示例对此进行了描述：digigene.com/design-patterns/dependency-injection-coffeeshop

真的很喜欢这个类比，因为它是简单的英语使用一个简单的类比。假设我是丰田，从设计到下线已经花费了太多的资金和人力来制造汽车，如果现有的知名轮胎生产商，我为什么要从头开始做一个轮胎制造部门，即{ 1}轮胎？我不。我所要做的就是从他们那里购买（通过参数注入），安装和哇啦！所以，回到编程，说一个C#项目需要使用一个现有的库/类，有两种方法可以运行/调试，1-添加对这个整个项目的引用

（续），.. 外部库/类，或从 DLL 中添加 2。除非我们必须查看这个外部类的内部内容，否则将其添加为 DLL 是一种更简单的方法。所以选项 1 是 new 它，选项 2 是作为参数传入。可能不准确，但简单愚蠢容易理解。

@JeliBeanMachine（很抱歉回复评论太晚了..）这不是我们删除第一个对象对轮对象或电池对象的依赖，而是我们将依赖传递给它，以便我们可以更改实例或实现依赖。之前：汽车对尼泊尔橡胶车轮有硬编码依赖。之后： Car 对 Wheel 的实例注入了依赖。

M

Mike

依赖注入是一种实践，其中对象的设计方式是从其他代码段接收对象的实例，而不是在内部构造它们。这意味着任何实现对象所需接口的对象都可以在不更改代码的情况下被替换，从而简化了测试，并提高了解耦性。

例如，考虑这些类：

public class PersonService {
  public void addManager( Person employee, Person newManager ) { ... }
  public void removeManager( Person employee, Person oldManager ) { ... }
  public Group getGroupByManager( Person manager ) { ... }
}

public class GroupMembershipService() {
  public void addPersonToGroup( Person person, Group group ) { ... }
  public void removePersonFromGroup( Person person, Group group ) { ... }
}

在此示例中，PersonService::addManager 和 PersonService::removeManager 的实现需要 GroupMembershipService 的实例才能完成其工作。如果没有依赖注入，执行此操作的传统方法是在 PersonService 的构造函数中实例化一个新的 GroupMembershipService 并在两个函数中使用该实例属性。但是，如果 GroupMembershipService 的构造函数有多个它需要的东西，或者更糟糕的是，需要在 GroupMembershipService 上调用一些初始化“设置器”，代码增长得相当快，而 PersonService 现在依赖于不仅在 GroupMembershipService 上，而且在 GroupMembershipService 所依赖的所有其他东西上。此外，与 GroupMembershipService 的链接被硬编码到 PersonService 中，这意味着您不能“虚拟化”一个 GroupMembershipService 用于测试目的，或者在应用程序的不同部分使用策略模式。

使用依赖注入，您可以将它传递给 PersonService 构造函数，或者添加一个属性（getter 和 setter）来设置它的本地实例，而不是在 PersonService 中实例化 GroupMembershipService。这意味着您的 PersonService 不再需要担心如何创建 GroupMembershipService，它只接受它给出的那些，并与它们一起工作。这也意味着 GroupMembershipService 的子类或实现 GroupMembershipService 接口的任何东西都可以“注入”到 PersonService 中，而 PersonService 不需要知道更改。

如果您可以在使用 DI 之后给出相同的代码示例，那就太好了

“这也意味着任何作为 GroupMembershipService 的子类或实现 GroupMembershipService 接口的东西都可以“注入”到 PersonService 中，而 PersonService 不需要知道更改。” ...这对我来说是一个非常有用的提示 - 谢谢！

z

zby

公认的答案是一个很好的答案——但我想补充一点，DI 非常类似于在代码中避免硬编码常量的经典做法。

当您使用一些常量（如数据库名称）时，您会快速将其从代码内部移动到某个配置文件，并将包含该值的变量传递到需要它的地方。这样做的原因是这些常量通常比代码的其余部分更频繁地更改。例如，如果您想在测试数据库中测试代码。

在面向对象编程的世界中，DI 与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。需要进行此类更改的一个重要案例是测试。

+1“对象比使用它们的代码更频繁地更改”。概括地说，在通量点添加一个间接。根据通量点，间接被称为不同的名称！

j

jcjr

让我们尝试使用 Car 和 Engine 类的简单示例，任何汽车都需要引擎才能去任何地方，至少现在是这样。下面是没有依赖注入的代码的外观。

public class Car
{
    public Car()
    {
        GasEngine engine = new GasEngine();
        engine.Start();
    }
}

public class GasEngine
{
    public void Start()
    {
        Console.WriteLine("I use gas as my fuel!");
    }
}

为了实例化 Car 类，我们将使用下面的代码：

Car car = new Car();

这段代码的问题是我们与 GasEngine 紧密耦合，如果我们决定将其更改为 ElectricityEngine，那么我们将需要重写 Car 类。应用程序越大，我们必须添加和使用新型引擎的问题和头痛就越多。

换句话说，这种方法是我们的高级 Car 类依赖于较低级别的 GasEngine 类，这违反了 SOLID 的依赖倒置原则 (DIP)。 DIP 建议我们应该依赖抽象，而不是具体的类。因此，为了满足这一点，我们引入了 IEngine 接口并重写了如下代码：

    public interface IEngine
    {
        void Start();
    }

    public class GasEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I use gas as my fuel!");
        }
    }

    public class ElectricityEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I am electrocar");
        }
    }

    public class Car
    {
        private readonly IEngine _engine;
        public Car(IEngine engine)
        {
            _engine = engine;
        }

        public void Run()
        {
            _engine.Start();
        }
    }

现在我们的 Car 类只依赖于 IEngine 接口，而不是引擎的具体实现。现在，唯一的技巧是我们如何创建 Car 的实例并为其提供一个实际的具体 Engine 类，例如 GasEngine 或 ElectricityEngine。这就是依赖注入的用武之地。

   Car gasCar = new Car(new GasEngine());
   gasCar.Run();
   Car electroCar = new Car(new ElectricityEngine());
   electroCar.Run();

在这里，我们基本上将我们的依赖项（Engine 实例）注入（传递）到 Car 构造函数。所以现在我们的类在对象和它们的依赖之间有了松散的耦合，我们可以很容易地添加新类型的引擎而不改变 Car 类。

依赖注入的主要好处是类更松散耦合，因为它们没有硬编码的依赖关系。这遵循上面提到的依赖倒置原则。类不是引用特定的实现，而是请求在构造类时提供给它们的抽象（通常是接口）。

所以说到底，依赖注入只是一种实现对象与其依赖之间松耦合的技术。不是直接实例化类执行其操作所需的依赖项，而是通过构造函数注入（最常见）向类提供依赖项。

此外，当我们有许多依赖项时，使用控制反转（IoC）容器是非常好的做法，我们可以告诉哪些接口应该映射到所有依赖项的哪些具体实现，并且我们可以让它在构造时为我们解决这些依赖项我们的对象。例如，我们可以在 IoC 容器的映射中指定 IEngine 依赖项应该映射到 GasEngine 类，当我们向 IoC 容器请求 Car 类的实例时，它会自动构造带有 GasEngine 依赖项的 Car 类通过了。

更新：最近观看了 Julie Lerman 的关于 EF Core 的课程，也喜欢她对 DI 的简短定义。

依赖注入是一种模式，允许您的应用程序动态地将对象注入到需要它们的类中，而无需强制这些类对这些对象负责。它允许您的代码更加松散耦合，并且 Entity Framework Core 插入到同一个服务系统中。

只是出于好奇，这与策略模式有何不同？这种模式封装了算法并使它们可互换。感觉依赖注入和策略模式非常相似。

这是一个很好的答案。

r

rgettman

假设你想去钓鱼：

如果没有依赖注入，您需要自己处理所有事情。你需要找一条船，买一根钓鱼竿，寻找诱饵，等等。当然有可能，但这会让你承担很多责任。用软件术语来说，这意味着您必须对所有这些东西进行查找。

通过依赖注入，其他人负责所有准备工作并为您提供所需的设备。您将收到（“被注射”）船、钓鱼竿和诱饵 - 都可以使用。

另一方面，假设你雇了一个水管工来重修你的浴室，然后他说：“太好了，这是我需要你帮我拿来的工具和材料清单”。这不应该是水管工的工作吗？

所以有人需要照顾一些它不知道的人..但仍然决定收集船、棍子和诱饵的清单 - 尽管准备好使用。

@JoshCaswell 不，那将是水管工的雇主的工作。作为客户，您需要完成管道。为此，您需要一名水管工。水管工需要它的工具。为了得到这些，它由管道公司配备。作为客户，您不想确切地知道管道工做什么或需要什么。作为水管工，您知道自己需要什么，但您只想做好自己的工作，而不是得到一切。作为水管工的雇主，您有责任在将水管工送到人们家中之前，为他们配备他们需要的东西。

@kai 我明白你的意思。在软件中，我们谈论的是工厂，对吗？但是 DI 通常也意味着该类不使用工厂，因为它仍然没有被注入。您，客户，需要联系雇主（工厂）为您提供工具，以便您可以传递给管道工。这不是它在程序中的实际工作方式吗？因此，虽然客户（调用类/功能/其他）不必购买工具，但他们仍然必须是中间人，以确保他们从雇主（工厂）那里得到管道工（注入类）。

@KingOfAllTrades：当然在某些时候你必须有人雇用和装备水管工，或者你没有水管工。但是你没有客户这样做。客户只需要一名管道工，并得到一个已经配备了他工作所需的东西。使用 DI，您最终仍然有一些代码来满足依赖关系。但是您将它与真正起作用的代码分开。如果你把它发挥到极致，你的对象只会让它们的依赖关系为人所知，并且对象图的构建发生在外部，通常在 init 代码中。

P

Pmpr.ir

This是我见过的关于Dependency Injection和Dependency Injection Container最简单的解释：

没有依赖注入

应用程序需要 Foo（例如控制器），所以：

应用程序创建 Foo

应用程序调用 Foo Foo 需要 Bar（例如服务），所以：Foo 创建 Bar Foo 调用 Bar Bar 需要 Bim（服务、存储库，...），所以：Bar 创建 Bim

Foo 需要 Bar（例如服务），所以：

Foo 创建 Bar

Foo 调用 Bar Bar 需要 Bim（服务、存储库……），所以： Bar 创建 Bim Bar 做某事

Bar 需要 Bim（服务、存储库……），所以：

Bar 创建 Bim

酒吧做点什么

依赖注入

应用需要Foo，需要Bar，需要Bim，所以：

应用程序创建 Bim

应用程序创建 Bar 并为其提供 Bim

应用程序创建 Foo 并给它 Bar

应用程序调用 Foo Foo 调用 Bar Bar 做某事

Foo 呼叫 Bar Bar 做某事

酒吧做点什么

使用依赖注入容器

应用程序需要 Foo 所以：

应用程序从 Container 中获取 Foo，因此： Container 创建 Bim Container 创建 Bar 并给它 Bim Container 创建 Foo 并给它 Bar

容器创建 Bim

Container 创建 Bar 并给它 Bim

Container 创建 Foo 并给它 Bar

应用程序调用 Foo Foo 调用 Bar Bar 做某事

Foo 呼叫 Bar Bar 做某事

酒吧做点什么

依赖注入和依赖注入容器是不同的东西：

依赖注入是一种编写更好代码的方法

DI Container 是帮助注入依赖项的工具

您不需要容器来进行依赖注入。但是，容器可以帮助您。

恕我直言，最好的答案在这里，因为它没有将 ioc 或构造函数注入与 di 混合。

c

cherryblossom

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

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

您会觉得现在维护这个工厂的所有任务太复杂了，因为除了主要任务（在组装单元中组装汽车）您还必须专注于其他单元。现在维护成本非常高，而且厂房很大，所以要多花钱租。

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

现在我们可以说，组装汽车的所有依赖项都是从供应商注入到工厂的。这是现实生活中的依赖注入（DI）的一个例子。

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

This 现在将通过技术解释帮助您学习 DI。 This 将显示何时使用 DI 以及何时应该使用 not。

https://i.stack.imgur.com/E7OWM.png

https://i.stack.imgur.com/auqDX.png

感谢这个概念的视觉表现！

T

TylerH

“依赖注入”不只是意味着使用参数化构造函数和公共设置器吗？

James Shore's article shows the following examples for comparison。

没有依赖注入的构造函数： public class Example { private DatabaseThingie myDatabase; public Example() { myDatabase = new DatabaseThingie(); } 公共无效 doStuff() { ... myDatabase.getData(); ... } } 具有依赖注入的构造函数： public class Example { private DatabaseThingie myDatabase;公共示例（DatabaseThingie useThisDatabaseInstead）{ myDatabase = useThisDatabaseInstead; } 公共无效 doStuff() { ... myDatabase.getData(); ... } }

当然，在 DI 版本中，您不想在无参数构造函数中初始化 myDatabase 对象吗？如果您尝试调用 DoStuff 而不调用重载的构造函数，似乎没有意义并且会引发异常？

仅当 new DatabaseThingie() 未生成有效的 myDatabase 实例时。

w

wakqasahmed

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

没有依赖注入

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

Switch -> PermanentBulb //switch 直接接永久灯泡，不易测试

https://i.stack.imgur.com/cIt97.jpg

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

依赖注入

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

Switch -> Bulb1 OR Bulb2 OR NightBulb（注入依赖）

https://i.stack.imgur.com/NrXaF.jpg

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(); 
    ... 
  } 
}`

C

Community

什么是依赖注入（DI）？

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

DI、DIP 和 SOLID

具体来说，在 Robert C Martin 的 SOLID principles of Object Oriented Design 范式中，DI 是 Dependency Inversion Principle (DIP) 的可能实现之一。 DIP is the D of the SOLID mantra - 其他 DIP 实现包括服务定位器和插件模式。

DIP 的目标是解耦类之间紧密的、具体的依赖关系，而是通过抽象来放松耦合，这可以通过 interface、abstract class 或 pure virtual class 来实现，具体取决于语言和使用的方法。

如果没有 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);
   }
}

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

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

public interface IClock
{
    DateTime Now { get; }
}

我们还可以将对 Console 的依赖放松为抽象，例如 TextWriter。依赖注入通常实现为 constructor 注入（将抽象传递给依赖项作为参数给消费类的构造函数）或 Setter Injection（通过 setXyz() 设置器或带有 { 的 .Net 属性传递依赖项） 6}定义）。构造函数注入是首选，因为这样可以保证类在构造后处于正确状态，并允许将内部依赖字段标记为 readonly (C#) 或 final (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.Now，并且这两个依赖项需要由 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());
}

下一步

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

每个抽象和配置的具体实现之间的映射（例如“任何时候消费者请求 IBar，返回一个 ConcreteBar 实例”）

可以为每个依赖项的生命周期管理设置策略，例如为每个消费者实例创建一个新对象，在所有消费者之间共享一个单例依赖实例，仅在同一个线程中共享相同的依赖实例等。

在 .Net 中，IoC 容器了解 IDisposable 等协议，并将承担根据配置的生命周期管理处理依赖项的责任。

通常，一旦 IoC 容器被配置/引导，它们就会在后台无缝运行，从而使编码人员可以专注于手头的代码，而不必担心依赖关系。

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

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

但是好处很多，特别是在彻底测试您感兴趣的课程的能力方面。

注意：POCO / POJO / 序列化 DTO / 实体图 / 匿名 JSON 投影等的创建/映射/投影（通过 new ..()） - 即“仅数据”类或记录 - 使用或返回from 方法不被视为依赖项（在 UML 意义上）并且不受 DI 约束。使用 new 投影这些就可以了。

问题是 DIP != DI。 DIP 是关于从实现中解耦抽象： A. 高级模块不应该依赖于低级模块。两者都应该依赖于抽象。 B. 抽象不应该依赖于细节。细节应该取决于抽象。 DI 是一种将对象创建与对象使用分离的方法。

是的，在 Bob 叔叔的 SOLID 范式中，我的第 2 段 “DI 是 DIP 的可能实现之一” 清楚地说明了区别。我在之前的帖子中也做了这个clear。

8

8 revs, 3 users 97%

依赖注入 (DI) 的全部意义在于保持应用程序源代码的干净和稳定：

清除依赖初始化代码

稳定，无论使用的依赖项如何

实际上，每个设计模式都会将关注点分开，以使未来的更改影响最小的文件。

DI 的具体领域是依赖配置和初始化的委托。

示例：带有 shell 脚本的 DI

如果您偶尔在 Java 之外工作，请回想一下 source 如何经常用于许多脚本语言（Shell、Tcl 等，甚至在 Python 中被滥用于此目的的 import）。

考虑简单的 dependent.sh 脚本：

#!/bin/sh
# Dependent
touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

该脚本是依赖的：它不会自行成功执行（archive_files 未定义）。

您在 archive_files_zip.sh 实施脚本中定义 archive_files（在本例中使用 zip）：

#!/bin/sh
# Dependency
function archive_files {
    zip files.zip "$@"
}

您可以使用包含两个“组件”的 injector.sh“容器”，而不是直接在依赖项中使用 source-ing 实现脚本：

#!/bin/sh 
# Injector
source ./archive_files_zip.sh
source ./dependent.sh

archive_files dependency 刚刚被注入到 dependent 脚本中。

您可以使用 tar 或 xz 注入实现 archive_files 的依赖项。

示例：删除 DI

如果 dependent.sh 脚本直接使用依赖项，则该方法称为依赖项查找（与依赖项注入相反）：

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

现在的问题是依赖的“组件”必须自己执行初始化。

“组件”的源代码既不干净也不稳定，因为依赖项初始化的每次更改都需要“组件”的源代码文件的新版本。

最后的话

DI 不像在 Java 框架中那样被广泛强调和普及。

但这是一种解决以下问题的通用方法：

应用程序开发（单一源代码发布生命周期）

应用程序部署（具有独立生命周期的多个目标环境）

仅将配置与依赖项查找一起使用并没有帮助，因为配置参数的数量可能会根据依赖项（例如新的身份验证类型）以及受支持的依赖项类型的数量（例如新的数据库类型）而改变。

我将添加完成特定类（测试）而不必完成其依赖项的能力，作为 DI 的目的。

C

Community

以上所有答案都很好，我的目的是用简单的方式解释这个概念，以便任何没有编程知识的人也能理解这个概念

依赖注入是帮助我们以更简单的方式创建复杂系统的设计模式之一。

我们可以在日常生活中看到这种模式的广泛应用。一些例子是磁带录音机、VCD、CD 驱动器等。

https://i.stack.imgur.com/Ubcrh.jpg

上图是 20 世纪中叶卷对卷便携式录音机的图像。 Source。

录音机的主要目的是记录或播放声音。

在设计系统时，它需要一个卷轴来记录或播放声音或音乐。设计这个系统有两种可能性

我们可以将卷轴放在机器内，我们可以为卷轴提供一个挂钩，可以放置它。

如果我们使用第一个，我们需要打开机器来更换卷轴。如果我们选择第二个，即为卷轴放置一个钩子，我们将获得通过更换卷轴播放任何音乐的额外好处。并且还减少了仅在卷轴中播放任何内容的功能。

同样，依赖注入是将依赖关系外部化以仅关注组件的特定功能的过程，以便可以将独立的组件耦合在一起以形成复杂的系统。

我们通过使用依赖注入获得的主要好处。

高内聚和松耦合。

外化依赖，只看责任。

将事物作为组件并组合成一个功能强大的大型系统。

它有助于开发高质量的组件，因为它们是独立开发的，并且经过了适当的测试。

如果一个组件出现故障，它有助于用另一个组件替换该组件。

现在，这些概念构成了编程世界中众所周知的框架的基础。 Spring Angular 等是建立在这个概念之上的知名软件框架

依赖注入是一种用于创建其他对象所依赖的对象实例的模式，而在编译时不知道哪个类将用于提供该功能，或者只是将属性注入对象的方式称为依赖注入。

依赖注入示例

以前我们是这样写代码的

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

使用依赖注入，依赖注入器将为我们取消实例化

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 
   
  dependentObject.someMethod();
}

你也可以阅读

Difference between Inversion of Control & Dependency Injection

I

Imam Bux

例如，我们有 2 个类 Client 和 Service。 Client 将使用 Service

public class Service {
    public void doSomeThingInService() {
        // ...
    }
}

没有依赖注入

方式1）

public class Client {
    public void doSomeThingInClient() {
        Service service = new Service();
        service.doSomeThingInService();
    }
}

方式2）

public class Client {
    Service service = new Service();
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

方式3）

public class Client {
    Service service;
    public Client() {
        service = new Service();
    }
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

1) 2) 3) 使用

Client client = new Client();
client.doSomeThingInService();

优点

简单的

缺点

很难测试客户端类

当我们更改服务构造函数时，我们需要在所有地方更改代码创建服务对象

使用依赖注入

方式一）构造函数注入

public class Client {
    Service service;

    Client(Service service) {
        this.service = service;
    }

    // Example Client has 2 dependency 
    // Client(Service service, IDatabas database) {
    //    this.service = service;
    //    this.database = database;
    // }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

使用

Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();

方式2）Setter注入

public class Client {
    Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

使用

Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();

方式3）接口注入

检查https://en.wikipedia.org/wiki/Dependency_injection

===

现在，这段代码已经在 Dependency Injection 之后，并且更容易测试 Client 类。
但是，我们仍然多次使用 new Service()，并且在更改 Service 构造函数时并不好。为了防止它，我们可以使用 DI 注射器，如
1) 简单手动 Injector

public class Injector {
    public static Service provideService(){
        return new Service();
    }

    public static IDatabase provideDatatBase(){
        return new SqliteDatabase();
    }
    public static ObjectA provideObjectA(){
        return new ObjectA(provideService(...));
    }
}

使用

Service service = Injector.provideService();

2) 使用库：对于 Android dagger2

优点

让测试更轻松

更改Service时，只需要在Injector类中更改即可

如果你使用构造函数注入，当你查看客户端的构造函数时，你会看到客户端类有多少依赖

缺点

如果你使用构造函数注入，Service对象是在创建Client时创建的，有时我们在Client类中使用函数而不使用Service，所以创建的Service是浪费的

依赖注入定义