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

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

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

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

清除依赖项初始化代码无论使用的依赖关系如何稳定

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

DI的特定域是依赖配置和初始化的委托。

示例：带有shell脚本的DI

如果您偶尔在Java之外工作，请回想一下源代码在许多脚本语言（Shell、Tcl等，甚至在Python中被误用）中的使用情况。

考虑简单的dependent.sh脚本：

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

脚本是依赖的：它无法单独成功执行（未定义存档文件）。

可以在archive_files_ip.sh实现脚本中定义archive_files（在本例中使用zip）：

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

您可以使用一个injector.sh“container”来包装这两个“components”，而不是直接在依赖脚本中源代码化实现脚本：

#!/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框架那样被广泛强调和普及。

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

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

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

摘自《扎实的Java开发人员：Java 7和多语言编程的关键技术》一书

DI是IoC的一种特殊形式，因此查找依赖项的过程是不受当前执行代码的直接控制。

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

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

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

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

现在我们可以说，组装汽车的所有依赖都是由供应商注入工厂的。这是一个真实的依赖注入（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(); 
    ... 
  } 
}`

简单来说，依赖注入（DI）是消除不同对象之间的依赖关系或紧密耦合的方法。依赖注入为每个对象提供一个内聚行为。

DI是国际奥委会春季原则的实施，该原则说“不要打电话给我们，我们会打电话给你”。使用依赖注入程序员不需要使用new关键字创建对象。

对象一旦加载到Spring容器中，我们就可以在需要时重用它们，方法是使用getBean（StringbeanName）方法从Spring容器中获取这些对象。