已经发布了几个关于依赖注入的具体问题，例如何时使用它以及它有什么框架，
什么是依赖注入，何时/为什么应该或不应该使用它？
当前回答
依赖注入（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是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见额外责任（负担）的技术。
DI使您更接近单一责任（SR）原则，就像外科医生可以专注于外科手术一样。
何时使用DI：我建议在几乎所有的生产项目（小型/大型）中使用DI，尤其是在不断变化的业务环境中：）
原因：因为您希望代码易于测试、可模拟等，以便快速测试更改并将其推向市场。此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不这样做呢。
到目前为止，我找到的最好的定义是詹姆斯·肖尔的定义：
“依赖注入”是25美元5美分概念的术语。[...]依赖注入意味着对象的实例变量。[...].
马丁·福勒的一篇文章可能也很有用。
依赖注入基本上是提供对象所需的对象（其依赖项），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许对依赖项进行嘲笑或清除。
依赖关系可以通过多种方式注入到对象中（例如构造函数注入或setter注入）。甚至可以使用专门的依赖注入框架（例如Spring）来实现这一点，但它们肯定不是必需的。您不需要这些框架进行依赖注入。显式实例化和传递对象（依赖项）与框架注入一样好。
依赖注入是一种实践，它使解耦的组件与它们的一些依赖不可知，这遵循SOLID准则
依赖反转原则：一个人应该“依赖于抽象，而不是结核。
依赖注入的更好实现是Composition Root设计模式，因为它允许组件与依赖注入容器分离。
我再次推荐这篇关于作文根的伟大文章http://blog.ploeh.dk/2011/07/28/CompositionRoot/作者：Mark Seemann
本文的要点如下：
合成根是应用程序中的（最好）唯一位置其中模块被组合在一起。
...
只有应用程序应该具有合成根。图书馆和框架不应该。
...
DI容器只能从合成根引用。所有其他模块都不应引用容器。
Di Ninja（依赖注入框架）的文档是一个很好的例子，可以演示组合根和依赖注入的原理是如何工作的。https://github.com/di-ninja/di-ninja正如我所知，是javascript中唯一实现Composition Root设计模式的DiC。
公认的答案是一个好答案——但我想补充一点，DI非常像代码中避免硬编码常量的经典做法。
当您使用诸如数据库名称之类的常量时，您可以将其从代码内部快速移动到某个配置文件，并将包含该值的变量传递到需要它的位置。这样做的原因是，这些常量通常比代码的其他部分更频繁地更改。例如，如果您想在测试数据库中测试代码。
在面向对象编程的世界中，DI与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变，那就是测试。
我知道已经有很多答案，但我发现这非常有用：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实例的任何类提供。
