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

（顺便说一句，是的，对于一个相当简单的概念，它已经成为一个过度炒作的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框架那样被广泛强调和普及。

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

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

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

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

我知道已经有很多答案，但我发现这非常有用：http://tutorials.jenkov.com/dependency-injection/index.html

无相关性：

public class MyDao {

  protected DataSource dataSource = new DataSourceImpl(
    "driver", "url", "user", "password");

  //data access methods...
  public Person readPerson(int primaryKey) {...}     
}

附属国：

public class MyDao {

  protected DataSource dataSource = null;

  public MyDao(String driver, String url, String user, String password) {
    this.dataSource = new DataSourceImpl(driver, url, user, password);
  }

  //data access methods...
  public Person readPerson(int primaryKey) {...}
}

注意DataSourceImpl实例化是如何移动到构造函数中的。构造函数接受四个参数，即DataSourceImpl所需的四个值。虽然MyDao类仍然依赖于这四个值，但它本身不再满足这些依赖关系。它们由创建MyDao实例的任何类提供。

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

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

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