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

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

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

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

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

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

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

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

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

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

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

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

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

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

针对5岁儿童的依赖注入。

当你自己去把冰箱里的东西拿出来时，你可能会引起问题。你可能会让门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。你甚至可能在寻找我们甚至没有或已经过期的东西。

你应该做的是陈述一个需要，“我需要午餐时喝点东西”，然后我们会确保你坐下吃饭时有东西。

让我们想象一下，你想去钓鱼：

没有依赖注入，你需要自己处理所有的事情。你需要找一艘船，买一根鱼竿，寻找诱饵等等。当然，这是可能的，但这给你带来了很多责任。在软件方面，这意味着你必须对所有这些东西进行查找。通过依赖注入，其他人负责所有准备工作，并为您提供所需的设备。你将收到（“被注射”）船、鱼竿和鱼饵——所有这些都准备好使用。

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

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

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