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

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

我们在应用程序中创建的对象（无论我们是否使用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与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变，那就是测试。

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

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

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

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

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

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

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

.

依赖注入是与Spring框架相关概念的核心。在创建任何项目的框架时，Spring都可能发挥重要作用，而依赖注入就是其中之一。

实际上，假设在java中，您创建了两个不同的类，即类A和类B，并且无论类B中有什么函数，您都希望在类A中使用，所以此时可以使用依赖注入。在这里，您可以将一个类的对象放入另一个类中，就像您可以将整个类注入另一个类别中以使其可访问一样。通过这种方式可以克服依赖性。

依赖注入只是将两个类粘合在一起，同时保持它们的分离。

来自Christoffer Noring，Pablo Deeleman的书《学习角度-第二版》：

“随着我们的应用程序的增长和发展，我们的每一个代码实体都将在内部需要其他对象的实例，在软件工程领域中，这些对象被称为依赖关系。将这些依赖关系传递给依赖客户端的动作被称为注入，它还需要另一个代码主体（称为注入器）的参与。注入器将负责用于实例化和引导所需依赖项的功能，以便它们从成功注入客户端的那一刻起就可以使用。这一点非常重要，因为客户机不知道如何实例化自己的依赖关系，只知道为了使用它们而实现的接口。"

发件人：Anton Moiseev。《字体角度发展，第二版》一书：

“简而言之，DI帮助您以松散耦合的方式编写代码，并使代码更易于测试和重用。”