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

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

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

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

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

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

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

.

“依赖注入”不就是指使用参数化构造函数和公共setter吗？

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

没有依赖注入的构造函数：公共类示例｛私有数据库Thingie myDatabase；public Example（）｛myDatabase=新数据库Thingie（）；} public void doStuff（）｛... myDatabase.getData（）；... } } 具有依赖注入的构造函数：公共类示例｛私有数据库Thingie myDatabase；公共示例（DatabaseThingie使用ThisDatabaseReplace）｛myDatabase=改用此数据库；}public void doStuff（）｛... myDatabase.getData（）；... } }

我将提出一个稍微不同的、简短而精确的依赖注入定义，侧重于主要目标，而不是技术手段（从这里开始）：

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

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

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

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

何时使用？我会说，每当应用程序足够大时，将逻辑封装到单独的模块中，在模块之间使用依赖关系图，可以提高代码的可读性和可探索性。

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

来源：了解依赖注入

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

例如，考虑Car对象。

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

无依赖注入（DI）：

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

  //The rest
}

在这里，Car对象负责创建从属对象。

如果我们希望在初始NepaliRubberWheel（）穿孔后更改其从属对象的类型（例如Wheel），该怎么办？我们需要重新创建Car对象及其新的依赖项，例如ChineseRubberWheel（），但只有Car制造商才能做到这一点。

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

当使用依赖注入时，对象在运行时而不是编译时（汽车制造时）被赋予依赖性。因此，我们现在可以随时更改轮子。在这里，相关性（轮子）可以在运行时注入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;
  }
}

其优点是：

分离对象的创建（换句话说，将使用与对象的创建分开）能够替换依赖项（例如：车轮、电池），而不改变使用它的类（汽车）促进“代码到接口而不是实现”原则在测试期间创建和使用模拟依赖关系的能力（如果我们想在测试期间使用模拟轮而不是真实实例，我们可以创建模拟轮对象并让DI框架注入Car）

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

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

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

到目前为止，我找到的最好的定义是詹姆斯·肖尔的定义：

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

马丁·福勒的一篇文章可能也很有用。

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

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