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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

编辑

Jose Maria Arranz对DI的美好评论

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

错误。依赖关系的方向是XML形式或注释，依赖关系是以XML代码和注释的形式编写的。XML和注释是源代码。

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

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

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

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