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

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

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

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

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

来自Christoffer Noring，Pablo Deeleman的书《学习角度-第二版》：

“随着我们的应用程序的增长和发展，我们的每一个代码实体都将在内部需要其他对象的实例，在软件工程领域中，这些对象被称为依赖关系。将这些依赖关系传递给依赖客户端的动作被称为注入，它还需要另一个代码主体（称为注入器）的参与。注入器将负责用于实例化和引导所需依赖项的功能，以便它们从成功注入客户端的那一刻起就可以使用。这一点非常重要，因为客户机不知道如何实例化自己的依赖关系，只知道为了使用它们而实现的接口。"

发件人：Anton Moiseev。《字体角度发展，第二版》一书：

“简而言之，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实例的任何类提供。

依赖注入是解决“依赖混淆”需求的一种可能方案。依赖性混淆是一种将“明显”性质从向需要依赖性的类提供依赖性的过程中去除的方法，因此在某种程度上混淆了向所述类提供所述依赖性。这不一定是坏事。事实上，通过混淆向类提供依赖项的方式，类外部的某个东西负责创建依赖项，这意味着在各种情况下，可以向类提供不同的依赖项实现，而不需要对类进行任何更改。这对于在生产和测试模式之间切换非常有用（例如，使用“模拟”服务依赖）。

不幸的是，糟糕的部分是，有些人认为你需要一个专门的框架来进行依赖性混淆，如果你选择不使用特定的框架来做，那么你在某种程度上就是一个“低级”程序员。另一个非常令人不安的神话是，依赖性注入是实现依赖性混淆的唯一方法。这显然是历史性的，显然是100%错误的，但你很难说服一些人，依赖项注入可以替代依赖项混淆需求。

多年来，程序员们已经了解了依赖性混淆的需求，在考虑依赖性注入之前和之后，许多替代解决方案都已经发展起来。有工厂模式，但也有许多使用ThreadLocal的选项，其中不需要对特定实例进行注入-依赖关系被有效地注入到线程中，这样做的好处是使对象（通过方便的静态getter方法）可用于任何需要它的类，而无需向需要它的类别添加注释并设置复杂的XML“粘合”以实现这一点。当持久性需要依赖项（JPA/JDO或其他）时，它允许您更容易地实现“跨持久性”，并且域模型和业务模型类完全由POJO组成（即没有特定于框架的/锁定在注释中的）。

例如，我们有两类客户机和服务。客户端将使用服务

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）