已经发布了几个关于依赖注入的具体问题，例如何时使用它以及它有什么框架，
什么是依赖注入，何时/为什么应该或不应该使用它？
当前回答
公认的答案是一个好答案——但我想补充一点，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年，当我写下这个答案时，这是谷歌测试博客的一个主要主题。这对我来说仍然是最大的优势，因为程序员在运行时设计中并不总是需要额外的灵活性（例如，服务定位器或类似模式）。程序员通常需要在测试期间隔离类。
依赖注入意味着一种方式（实际上是任何方式），代码的一部分（例如类）可以以模块化的方式访问依赖项（代码的其他部分，例如它所依赖的其他类），而不必对它们进行硬编码（因此它们可以自由更改或重写，甚至可以根据需要在其他时间加载）
（顺便说一句，是的，对于一个相当简单的概念，它已经成为一个过度炒作的25美元的名字），我的25美分
公认的答案是一个好答案——但我想补充一点，DI非常像代码中避免硬编码常量的经典做法。
当您使用诸如数据库名称之类的常量时，您可以将其从代码内部快速移动到某个配置文件，并将包含该值的变量传递到需要它的位置。这样做的原因是，这些常量通常比代码的其他部分更频繁地更改。例如，如果您想在测试数据库中测试代码。
在面向对象编程的世界中，DI与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变，那就是测试。
简单来说，依赖注入（DI）是消除不同对象之间的依赖关系或紧密耦合的方法。依赖注入为每个对象提供一个内聚行为。
DI是国际奥委会春季原则的实施，该原则说“不要打电话给我们，我们会打电话给你”。使用依赖注入程序员不需要使用new关键字创建对象。
对象一旦加载到Spring容器中，我们就可以在需要时重用它们，方法是使用getBean（StringbeanName）方法从Spring容器中获取这些对象。
例如，我们有两类客户机和服务。客户端将使用服务
public class Service {
public void doSomeThingInService() {
// ...
}
}
无依赖注入
方式1）
public class Client {
public void doSomeThingInClient() {
Service service = new Service();
service.doSomeThingInService();
}
}
方式2）
public class Client {
Service service = new Service();
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
方式3）
public class Client {
Service service;
public Client() {
service = new Service();
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
1） 2）3）使用
Client client = new Client();
client.doSomeThingInService();
优势
易于理解的
缺点
难以测试客户端类当我们更改Service构造函数时，我们需要在所有位置更改代码createService对象
使用依赖注入
方式1）构造函数注入
public class Client {
Service service;
Client(Service service) {
this.service = service;
}
// Example Client has 2 dependency
// Client(Service service, IDatabas database) {
// this.service = service;
// this.database = database;
// }
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();
方式2）沉淀剂注入
public class Client {
Service service;
public void setService(Service service) {
this.service = service;
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();
方式3）接口注入
检查https://en.wikipedia.org/wiki/Dependency_injection
===
现在，这段代码已经遵循了依赖注入，测试客户端类更容易。然而，我们仍然多次使用新的Service（），并且在更改Service构造函数时效果不佳。为了防止这种情况，我们可以使用DI注射器1） 简单手动喷油器
public class Injector {
public static Service provideService(){
return new Service();
}
public static IDatabase provideDatatBase(){
return new SqliteDatabase();
}
public static ObjectA provideObjectA(){
return new ObjectA(provideService(...));
}
}
使用
Service service = Injector.provideService();
2） 使用库：适用于Android dagger2
优势
使测试更容易更改服务时，只需在Injector类中更改如果您使用使用构造函数注入，当您查看Client的构造函数时，您将看到Client类有多少依赖项
缺点
如果使用构造函数注入，则在创建客户端时创建服务对象，有时我们在客户端类中使用函数而不使用服务，因此创建的服务被浪费
依赖注入定义
https://en.wikipedia.org/wiki/Dependency_injection
依赖项是可以使用的对象（服务）注入是将依赖项（Service）传递给将使用它的依赖对象（Client）
