流行的答案毫无用处，因为它们以一种无用的方式定义依赖注入。让我们同意，“依赖性”是指我们的对象X所需要的一些预先存在的其他对象。但当我们说

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

我们只调用将参数传递到构造函数中。自从构造器被发明以来，我们一直在定期这样做。

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

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

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

在执行

gcc foo.o bar.o -o bar

键入“makebar”的人不需要知道bar依赖于foo。在“makebar”和gcc之间注入了依赖关系。

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

通常，中间层为构造的对象提供工厂，这些对象必须提供每个请求的对象类型都必须满足的角色。这是因为通过拥有一个隐藏构建细节的中间层，您已经受到了工厂施加的抽象惩罚，所以您不妨使用工厂。

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

（顺便说一句，是的，对于一个相当简单的概念，它已经成为一个过度炒作的25美元的名字），我的25美分

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

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

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

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

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

依赖注入（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框架那样被广泛强调和普及。

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

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

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

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

例如，考虑这些类：

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的构造函数有多个它需要的东西，或者更糟的是，需要在GroupMembershipServices上调用一些初始化“setter”，代码增长相当快，PersonService现在不仅依赖于GroupMembershipService，还依赖于GroupMembershipService所依赖的所有其他东西。此外，与GroupMembershipService的链接被硬编码到PersonService中，这意味着您不能为了测试目的而“虚拟”GroupMembershipServices，或者在应用程序的不同部分使用策略模式。

使用依赖注入，而不是在PersonService中实例化GroupMembershipService，您可以将其传递给PersonService构造函数，或者添加Property（getter和setter）来设置其本地实例，并与他们合作。这也意味着，任何属于GroupMembershipService的子类或实现GroupMembershipServices接口的内容都可以“注入”到PersonService中，PersonService不需要知道更改。

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

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

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