什么是依赖注入？

Question

已经发布了几个关于依赖注入的具体问题，例如何时使用它以及有哪些框架。 但是，

什么是依赖注入以及何时/为什么应该或不应该使用它？

Answer 1

我知道已经有很多答案，但我发现这非常有帮助： http://tutorials .jenkov.com/dependency-injection/index.html

无依赖关系：

public class MyDao {

  protected DataSource dataSource = new DataSourceImpl(
    "driver", "url", "user", "password");

  //data access methods...
  public Person readPerson(int primaryKey) {...}     
}

依赖关系：

public class MyDao {

  protected DataSource dataSource = null;

  public MyDao(String driver, String url, String user, String password) {
    this.dataSource = new DataSourceImpl(driver, url, user, password);
  }

  //data access methods...
  public Person readPerson(int primaryKey) {...}
}

注意如何将 DataSourceImpl 实例化移动到构造函数中。 构造函数采用四个参数，即 DataSourceImpl 所需的四个值。 尽管 MyDao 类仍然依赖于这四个值，但它本身不再满足这些依赖关系。 它们由创建 MyDao 实例的任何类提供。

Answer 2

摘自Apress.Spring.Persistence.with.Hibernate.Oct.2010
一书

依赖注入的目的是解耦
解决应用程序业务中的外部软件组件问题
逻辑。没有依赖注入，组件如何的细节
访问所需的服务可能会与组件的混乱
代码。 这不仅增加了出错的可能性，还增加了代码
臃肿，并增加维护复杂性； 它耦合组件
更紧密地结合在一起，使得修改依赖关系变得困难
重构或测试。

Answer 3

到目前为止，我找到的最好的定义是 James Shore 的定义：

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

Martin Fowler 的一篇文章也可能有用。

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

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

Answer 4

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

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

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 测试博客 上的一个主要主题。 这对我来说仍然是最大的优势，因为程序员并不总是需要在运行时设计中具有额外的灵活性（例如，服务定位器或类似的模式）。 程序员经常需要在测试期间隔离类。

Answer 5

我在松散耦合方面发现了这个有趣的例子：

来源：< em>了解依赖注入

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

例如，考虑一个 Car 对象。

汽车依靠车轮、发动机、燃料、电池等来运行。 传统上，我们定义此类依赖对象的品牌以及 Car 对象的定义。

没有依赖注入 (DI)：

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

  //The rest
}

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

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

那么依赖注入为我们做了什么......？

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

使用依赖项注入后：

在这里，我们在运行时注入依赖项（车轮和电池）。 因此出现了术语：依赖注入。我们通常依赖 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），而无需更改使用它的类（Car）
• 促进“代码到接口而不是实现”原则
• 在测试期间创建和使用模拟依赖项的能力（如果我们想在测试期间使用模拟轮而不是真实实例..我们可以创建模拟轮对象并让 DI 框架注入车）

Answer 6

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

例如，考虑以下类：

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 上调用一些初始化“setter”，那么代码就会增长速度相当快，PersonService 现在不仅依赖于 GroupMembershipService，还依赖于 GroupMembershipService 所依赖的其他所有内容。 此外，与 GroupMembershipService 的链接被硬编码到 PersonService 中，这意味着您无法出于测试目的“虚拟”GroupMembershipService，或者在应用程序的不同部分使用策略模式。

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

Answer 7

让我们尝试一下 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 类，它将自动构造我们的 Car 类，并传入 GasEngine 依赖项。

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

依赖注入是一种允许应用程序注入的模式
动态地将对象传递给需要它们的类，而不强制这些对象
负责这些对象的类。 它允许你的代码是
耦合更加松散，Entity Framework Core 也可以插入其中
服务体系。

Answer 8

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

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

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

Answer 9

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

在第一张图片中，假设您有一个拥有大量车辆的汽车工厂。 汽车实际上是在装配单元中制造出来的，但它需要发动机、座椅以及车轮。 因此，装配单元依赖于所有这些单元，并且它们是工厂的依赖性。

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

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

现在我们可以说组装汽车的所有依赖项都是从提供商注入到工厂的。 这是现实生活中依赖注入 (DI) 的示例。

现在用技术术语来说，依赖注入是一种技术，一个对象（或静态方法）通过该技术提供另一个对象的依赖关系。 所以，把创建对象的任务交给别人，直接使用依赖就叫做依赖注入。

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

。

Answer 10

这是关于依赖注入和依赖注入最简单的解释容器我见过：

没有依赖注入

• 应用程序需要Foo（例如控制器），所以：
• 应用程序创建Foo
• 应用程序调用Foo
  • Foo 需要 Bar（例如服务），因此：
  • Foo 创建 Bar
  • Foo 调用 Bar
    • Bar 需要 Bim（服务、存储库、
      ...），所以：
    • Bar 创建 Bim
    • 酒吧做了一些事情

使用依赖注入执行

• 某些操作 应用程序需要 Foo，而 Foo 又需要 Bar，而 Bar 又需要 Bim，所以：
• 应用程序创建 Bim
• 应用程序创建 Bar 并为其提供 Bim
• 应用程序创建 Foo 并为其提供 Bar
• 应用程序调用 Foo
  • Foo 调用 Bar
    • 酒吧做了一些事情

使用依赖注入容器执行

• 某些操作应用程序需要 Foo，因此：
• 应用程序从容器获取 Foo，因此：
  • 容器创建 Bim
  • 容器创建 Bar 并赋予它 Bim
  • 容器创建 Foo 并赋予它 Bar
• 应用程序调用 Foo
  • Foo 调用 Bar
    • 酒吧做了一些事情

依赖注入和依赖注入容器是不同的事情：

• 依赖注入是一种编写更好代码的方法
• DI容器是帮助注入依赖项的工具

您不需要容器来进行依赖项注入。 然而，容器可以帮助你。

Answer 11

让我们想象一下，您想去钓鱼：

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

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

Answer 12

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

James Shore 的文章展示了以下示例进行比较。

没有依赖注入的构造函数：

公共类示例 {  
    私有数据库Thingie myDatabase；  

    公共示例（）{  
      myDatabase = new DatabaseThingie();  
    }  

    公共无效doStuff（）{  
      ...  
      myDatabase.getData();  
      ...  
    }  
  }  
  

具有依赖注入的构造函数：

公共类示例 {  
    私有数据库Thingie myDatabase；  

    公共示例（DatabaseThingie useThisDatabaseInstead）{  
      myDatabase = 使用此数据库代替；  
    } 

    公共无效doStuff（）{  
      ...  
      myDatabase.getData();  
      ...  
    }  
  } 
  

Answer 13

使依赖注入概念变得简单易懂。 让我们以开关按钮来切换（开/关）灯泡为例。

如果没有依赖注入，

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

切换-> PermanentBulb //开关直接连接到永久灯泡，无法轻松测试

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

使用依赖注入

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

切换-> Bulb1 OR Bulb2 OR NightBulb（注入依赖项）

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

Answer 14

什么是依赖注入 (DI)？

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

DI、DIP 和 SOLID

具体来说，在 Robert C Martin 的 面向对象设计的SOLID原则，DI是依赖倒置原则（DIP）。 DIP 是 SOLID 口头禅的 D - 其他 DIP实现包括服务定位器和插件模式。

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

如果没有 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# 实现。 给出下面的 Consuming 类：

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

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

然而，我们可以将DIP应用于此类，通过将时间戳问题抽象为依赖关系，并将MyLogger仅耦合到一个简单的接口：

public interface IClock
{
    DateTime Now { get; }
}

我们还可以放松依赖关系在 Console 上到抽象，例如 TextWriter。 依赖注入通常实现为构造函数注入（将抽象传递给依赖项作为参数传递给消费类的构造函数）或 Setter 注入（通过setXyz() setter 或定义了 {set;} 的 .Net 属性）。 构造函数注入是首选，因为这可以保证类在构造后处于正确的状态，并允许将内部依赖字段标记为 readonly (C#) 或 final (爪哇）。 因此，在上面的示例中使用构造函数注入，这给我们留下了：（

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

后续步骤

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

• 每个抽象和配置的具体实现之间的映射（例如“任何时候消费者请求 IBar 时”） code>，返回一个ConcreteBar实例”）
• 可以为每个依赖项的生命周期管理设置策略，例如为每个消费者实例创建一个新对象，共享一个单例依赖项实例在所有消费者之间，仅在同一线程之间共享相同的依赖项实例，等等。
• 在 .Net 中，IoC 容器知道诸如 IDisposable 之类的协议，并将承担处理的责任/code> 依赖关系符合配置的生命周期管理。

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

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

如上面的示例，依赖项的解耦确实需要一些设计工作，对于开发人员来说，有一个范例这种转变需要打破直接新建依赖项的习惯，而是信任容器来管理依赖项。

但好处有很多，特别是能够彻底测试您感兴趣的类别。

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

Answer 15

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

• 依赖初始化代码干净
• 稳定< /strong> 无论使用什么依赖项

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

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

示例：使用 shell 脚本进行 DI

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

考虑简单的 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 "$@"
}

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

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

archive_files 依赖项刚刚已注入到依赖脚本中。

您可以使用 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 框架那样受到重视和普及。

但这是一种通用方法来划分以下方面的关注点：

• 应用程序开发（单个源代码发布生命周期）
• 应用程序部署（多个 > 具有独立生命周期的目标环境）

仅将配置与依赖项查找结合使用并无帮助，因为每个依赖项的配置参数数量（例如新的身份验证类型）以及受支持的依赖项类型的数量（例如新的身份验证类型）可能会发生变化。数据库类型）。

Answer 16

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

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

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

上图是 Reel-to-reel 便携式磁带录音机，20 世纪中期的图像世纪。 来源。

录音机的主要用途是录制或播放声音。

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

1. 我们可以将卷轴放置在机器内部，
2. 我们可以为卷轴提供一个可以放置它的钩子。

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

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

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

• 高内聚、松耦合。
• 将依赖外部化，只关注责任。
• 将事物作为组件并组合起来形成具有高性能的大型系统。
• 它有助于开发高质量的组件，因为它们是独立开发的并且经过适当的测试。
• 如果一个组件出现故障，它有助于用另一个组件替换该组件。

如今，这些概念构成了编程世界中众所周知的框架的基础。
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();
}

您还可以阅读

控制反转与控制反转之间的区别 依赖注入

Answer 17

例如，我们有 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();

优点

• 简单

缺点

• 难以测试 Client 类
• 当我们更改 时Service 构造函数，我们需要在创建 Service 对象的所有地方更改代码

使用依赖注入

方式 1) 构造函数注入

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

===

现在，这段代码已经遵循依赖注入并且更容易测试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类中改变它
• 如果你使用使用构造函数注入 >，当你查看Client的构造函数时，你会看到Client类有多少依赖

缺点

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

依赖注入定义

https://en.wikipedia。 org/wiki/Dependency_injection

依赖项是一个可以使用的对象（Service）
注入是将依赖项 (Service) 传递给使用它的依赖对象 (Client)

Answer 18

什么是依赖注入？

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

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

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

控制反转 (IOC)

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

依赖注入的两种类型：

1. 构造函数注入
2. Setter 注入

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 作为必需的依赖项。

Answer 19

这意味着对象应该只具有完成其工作所需的依赖项，并且依赖项应该很少。 此外，如果可能的话，对象的依赖关系应该依赖于接口，而不是“具体”对象。 （具体对象是使用关键字 new 创建的任何对象。）松散耦合促进了更大的可重用性、更容易的可维护性，并允许您轻松地提供“模拟”对象来代替昂贵的服务。

“依赖注入”（DI）也称为“控制反转”（IoC），可以用作促进这种松散耦合的技术。

实现 DI 有两种主要方法：

1. 构造函数注入
2. Setter 注入

构造函数注入

这是将对象依赖项传递给其构造函数的技术。

请注意，构造函数接受接口而不是具体对象。 另请注意，如果 orderDao 参数为 null，则会引发异常。 这强调了接收有效依赖的重要性。 在我看来，构造函数注入是为对象提供依赖项的首选机制。 开发人员在调用对象时很清楚需要将哪些依赖项提供给“Person”对象才能正确执行。

Setter 注入

但请考虑以下示例...假设您有一个类，其中有 10 个没有依赖项的方法，但您要添加一个确实依赖于 IDAO 的新方法。 您可以更改构造函数以使用构造函数注入，但这可能会迫使您更改整个地方的所有构造函数调用。 或者，您可以只添加一个接受依赖项的新构造函数，但是开发人员如何轻松知道何时使用一个构造函数而不是另一个构造函数。 最后，如果创建依赖项的成本非常昂贵，那么为什么要创建它并将其传递给构造函数，而它可能很少使用呢？ “Setter 注入”是另一种可以在这种情况下使用的 DI 技术。

Setter 注入不会强制将依赖项传递给构造函数。 相反，依赖关系被设置到需要的对象公开的公共属性上。 正如前面所暗示的，这样做的主要动机包括：

1. 支持依赖项注入，而无需修改遗留类的构造函数。
2. 允许尽可能晚地且仅在需要时创建昂贵的资源或服务。

以下是上述代码的示例：

public class Person {
    public Person() {}

    public IDAO Address {
        set { addressdao = value; }
        get {
            if (addressdao == null)
              throw new MemberAccessException("addressdao" +
                             " has not been initialized");
            return addressdao;
        }
    }

    public Address GetAddress() {
       // ... code that uses the addressdao object
       // to fetch address details from the datasource ...
    }

    // Should not be called directly;
    // use the public property instead
    private IDAO addressdao;

Answer 20

我能想到的最好的比喻是手术室里的外科医生和他的助手，外科医生是主要人物，他的助手在他需要时提供各种手术部件，以便外科医生可以专注于其中一个他最擅长的事情（手术）。 如果没有助手，外科医生每次需要部件时都必须自己去获取部件。

DI 简称 DI，是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见附加责任（负担）的技术。

DI 让您更接近单一职责 (SR) 原则，就像外科医生可以专注于手术。

何时使用 DI ：我建议在几乎所有生产项目（小/大）中使用 DI，特别是在不断变化的业务环境中:)

原因：因为您希望您的代码易于测试、可模拟等，以便您可以快速测试您的代码改变并推向市场。 此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不呢？

Answer 21

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

（还有 PS，是的，它已经成为一个过度炒作的 25 美元名称，一个相当简单的概念），我的 .25 美分

Answer 22

流行的答案是没有帮助的，因为它们以一种没有用的方式定义依赖注入。 我们一致认为，“依赖”是指我们的对象 X 需要的一些预先存在的其他对象。 ”时，我们并不是说我们正在执行“依赖注入”

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

但是，当我们说“我们只是调用将参数传递到构造函数中 。 自从构造函数被发明以来，我们就一直定期这样做。

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

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

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

在执行 a 之前先执行 a。

gcc foo.o bar.o -o bar

输入“make bar”的人不需要知道 bar 依赖于 foo。 依赖关系被注入到“make bar”和 gcc 之间。

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

通常，中间层为构造的对象提供工厂，它必须提供每个请求的对象类型必须满足的角色。 这是因为通过隐藏构造细节的中间级别，您已经遭受了工厂施加的抽象惩罚，因此您不妨使用工厂。

Answer 23

摘自本书，“基础良好的 Java 开发人员：Java 7 和多语言编程的重要技术

DI 是 IoC 的一种特殊形式，查找依赖项的过程是
超出当前执行代码的直接控制范围。

Answer 24

依赖注入是解决通常被称为“依赖混淆”需求的一种可能的解决方案。 依赖关系混淆是一种从向需要该依赖关系的类提供依赖关系的过程中去除“明显”性质的方法，从而以某种方式混淆向所述类提供所述依赖关系。 这不一定是坏事。 事实上，通过混淆向类提供依赖项的方式，类外部的某些东西负责创建依赖项，这意味着在各种情况下，可以向类提供依赖项的不同实现，而无需进行任何更改到班级。 这对于在生产和测试模式之间切换（例如，使用“模拟”服务依赖项）非常有用。

不幸的是，不好的部分是，有些人认为您需要一个专门的框架来进行依赖项混淆，并且如果您选择不使用特定的框架来执行此操作，那么您在某种程度上是一个“次要”程序员。 许多人相信的另一个极其令人不安的神话是，依赖项注入是实现依赖项混淆的唯一方法。 从历史上看，这显然是 100% 错误的，但你很难说服一些人，有依赖注入的替代方案来满足你的依赖混淆需求。

程序员多年来一直了解依赖关系混淆的要求，并且在依赖关系注入之前和之后已经发展了许多替代解决方案。 有工厂模式，但也有许多使用 ThreadLocal 的选项，其中不需要注入特定实例 - 依赖项被有效地注入到线程中，其优点是使对象可用（通过方便的静态 getter 方法）任何需要它的类，而无需向需要它的类添加注释并设置复杂的 XML“粘合剂”来​​实现它。 当您的依赖项需要持久性（JPA/JDO 或其他）时，它允许您更轻松地实现“透明持久性”，并且域模型和业务模型类纯粹由 POJO 组成（即没有特定于框架/锁定在注释中）。

Answer 25

5 岁孩子的依赖注入。

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

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

Answer 26

简而言之，依赖注入（DI）是消除不同对象之间的依赖关系或紧密耦合的方法。 依赖注入为每个对象提供了有凝聚力的行为。

DI 是 Spring 的 IOC 原则的实现，即“不要打电话给我们，我们会打电话给你”。 使用依赖注入程序员不需要使用new关键字创建对象。

对象一旦加载到 Spring 容器中，然后我们就可以在需要时通过使用 getBean(String beanName) 方法从 Spring 容器中获取这些对象来重用它们。

Answer 27

我想既然每个人都为 DI 编写过，让我问几个问题。

1. 当你有 DI 的配置时，所有实际实现（而不是接口）将被注入到一个类中（例如控制器的服务）为什么这不是某种硬编码？
2. 如果我想在运行时更改对象怎么办？ 例如，我的配置已经说明当我实例化 MyController 时，将 FileLogger 作为 ILogger 注入。 但我可能想注入 DatabaseLogger。
3. 每次我想要更改 AClass 需要的对象时，我现在都需要查看两个地方 - 类本身和配置文件。 这如何让生活变得更轻松？
4. 如果不注入AClass的Aproperty，是不是更难模拟出来？
5. 回到第一个问题。 如果使用 new object() 不好，为什么我们要注入实现而不是接口呢？ 我想你们很多人都说我们实际上是在注入接口，但配置使您指定该接口的实现..不是在运行时..它在编译时是硬编码的。

这是基于 @Adam N 发布的答案。

为什么PersonService 不再需要担心GroupMembershipService 呢？ 您刚刚提到 GroupMembership 有多个它依赖的东西（对象/属性）。 如果 PService 中需要 GMService，则您可以将其作为属性。 无论您是否注入它，您都可以模拟它。 我唯一希望注入的情况是 GMService 有更具体的子类，而您直到运行时才知道这些子类。 然后你想要注入子类。 或者，如果您想将其用作单例或原型。 老实说，配置文件对所有内容进行了硬编码，包括在编译时注入类型（接口）的子类。

编辑

Jose Maria Arranz 对 DI 的精彩评论

< em>DI 通过消除确定依赖方向和编写任何粘合代码的需要来增加内聚性。

错。 依赖项的方向是 XML 形式或作为注释，您的依赖项被编写为 XML 代码和注释。 XML 和注释是源代码。

DI 通过使所有组件模块化（即可替换）并具有明确定义的相互接口来减少耦合。

错误。 您不需要 DI 框架来构建基于接口的模块化代码。

关于可替换：使用非常简单的 .properties 存档和 Class.forName 您可以定义哪些类可以更改。 如果您的代码的任何类都可以更改，那么 Java 不适合您，请使用脚本语言。 顺便说一句：如果不重新编译，注释就无法更改。

在我看来，使用 DI 框架的唯一原因只有一个：减少样板。 有了一个做得好的工厂系统，您可以做与您首选的 DI 框架相同、更受控制、更可预测的事情，DI 框架承诺减少代码（XML 和注释也是源代码）。 问题是，在非常非常简单的情况下（每个类一个实例和类似的情况），这种样板文件的减少是真实存在的，有时在现实世界中选择适当的服务对象并不像将类映射到单例对象那么容易。

Answer 28

依赖注入（DI）是依赖倒置原则（DIP）实践的一部分，也称为控制反转（IoC）。 基本上，您需要进行 DIP，因为您希望使代码更加模块化和单元可测试，而不仅仅是一个整体系统。 因此，您开始识别可以从类中分离并抽象出来的代码部分。 现在需要从类外部注入抽象的实现。 通常这可以通过构造函数来完成。 因此，您创建一个接受抽象作为参数的构造函数，这称为依赖项注入（通过构造函数）。 有关 DIP、DI 和 IoC 容器的更多说明，您可以阅读 这里

Answer 29

依赖注入（DI）是设计模式中的一种，它使用 OOP 的基本特征——一个对象与另一个对象的关系。 虽然继承继承一个对象来执行更复杂和更具体的另一个对象，但关系或关联只是使用属性从一个对象创建指向另一个对象的指针。 DI 的强大之处在于与 OOP 的其他功能（如接口和隐藏代码）相结合。
假设，我们在图书馆有一个客户（订阅者），为了简单起见，他只能借一本书。

书籍界面：

package com.deepam.hidden;

public interface BookInterface {

public BookInterface setHeight(int height);
public BookInterface setPages(int pages);   
public int getHeight();
public int getPages();  

public String toString();
}

接下来我们可以有多种书籍； 其中一种类型是小说：

package com.deepam.hidden;

public class FictionBook implements BookInterface {
int height = 0; // height in cm
int pages = 0; // number of pages

/** constructor */
public FictionBook() {
    // TODO Auto-generated constructor stub
}

@Override
public FictionBook setHeight(int height) {
  this.height = height;
  return this;
}

@Override
public FictionBook setPages(int pages) {
  this.pages = pages;
  return this;      
}

@Override
public int getHeight() {
    // TODO Auto-generated method stub
    return height;
}

@Override
public int getPages() {
    // TODO Auto-generated method stub
    return pages;
}

@Override
public String toString(){
    return ("height: " + height + ", " + "pages: " + pages);
}
}

现在订阅者可以与这本书关联：

package com.deepam.hidden;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class Subscriber {
BookInterface book;

/** constructor*/
public Subscriber() {
    // TODO Auto-generated constructor stub
}

// injection I
public void setBook(BookInterface book) {
    this.book = book;
}

// injection II
public BookInterface setBook(String bookName) {
    try {
        Class<?> cl = Class.forName(bookName);
        Constructor<?> constructor = cl.getConstructor(); // use it for parameters in constructor
        BookInterface book = (BookInterface) constructor.newInstance();
        //book = (BookInterface) Class.forName(bookName).newInstance();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return book;
}

public BookInterface getBook() {
  return book;
}

public static void main(String[] args) {

}

}

所有三个类都可以隐藏以用于其自己的实现。 现在我们可以使用这段代码进行 DI：

package com.deepam.implement;

import com.deepam.hidden.Subscriber;
import com.deepam.hidden.FictionBook;

public class CallHiddenImplBook {

public CallHiddenImplBook() {
    // TODO Auto-generated constructor stub
}

public void doIt() {
    Subscriber ab = new Subscriber();

    // injection I
    FictionBook bookI = new FictionBook();
    bookI.setHeight(30); // cm
    bookI.setPages(250);
    ab.setBook(bookI); // inject
    System.out.println("injection I " + ab.getBook().toString());

    // injection II
    FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set
    System.out.println("injection II " + ab.getBook().toString());      
}

public static void main(String[] args) {
    CallHiddenImplBook kh = new CallHiddenImplBook();
    kh.doIt();
}
}

有很多不同的方法可以使用依赖注入。 可以将它与Singleton等结合起来，但基本上它只是通过在另一个对象中创建对象类型的属性来实现关联。
有用性仅在于功能，我们应该一次又一次编写的代码始终为我们准备好并完成。 这就是为什么 DI 与控制反转 (IoC) 如此紧密地结合在一起，这意味着我们的程序将控制权传递给另一个正在运行的模块，该模块将 bean 注入到我们的代码中。 （每个可以注入的对象都可以被签名或视为 Bean。）例如，在 Spring 中，它是通过创建和初始化 ApplicationContext 容器来完成的，它为我们完成了这项工作。 我们只需在代码中创建 Context 并调用 beans 的初始化。 在那一刻注射已经自动完成。

Answer 30

我会对依赖注入提出一个稍微不同的、简短而精确的定义，重点关注主要目标，而不是技术手段（遵循此处）：

依赖注入是创建静态、无状态的过程
服务对象图，其中每个服务都由其参数化
依赖关系。

我们在应用程序中创建的对象（无论我们是否使用 Java、C# 或其他面向对象语言）通常属于两类之一：无状态、静态和全局“服务对象”（模块），以及有状态、动态和本地“数据对象”。

模块图（服务对象图）通常在应用程序启动时创建。 这可以使用容器（例如 Spring）来完成，但也可以通过将参数传递给对象构造函数来手动完成。 两种方法都有其优点和缺点，但在应用程序中使用 DI 绝对不需要框架。

一项要求是服务必须根据其依赖性进行参数化。 这到底意味着什么取决于给定系统中采用的语言和方法。 通常，这采用构造函数参数的形式，但使用 setter 也是一种选择。 这也意味着服务的依赖关系对服务的用户是隐藏的（当调用服务方法时）。

什么时候使用？ 我想说，只要应用程序足够大，将逻辑封装到单独的模块中，并在模块之间使用依赖关系图，就可以提高代码的可读性和可探索性。