依赖注入是一种实践，其中对象的设计方式是从其他代码段接收对象实例，而不是在内部构造它们。这意味着可以在不更改代码的情况下替换实现对象所需接口的任何对象，这简化了测试，并改进了去耦。

例如，考虑这些类：

public class PersonService {
  public void addManager( Person employee, Person newManager ) { ... }
  public void removeManager( Person employee, Person oldManager ) { ... }
  public Group getGroupByManager( Person manager ) { ... }
}

public class GroupMembershipService() {
  public void addPersonToGroup( Person person, Group group ) { ... }
  public void removePersonFromGroup( Person person, Group group ) { ... }
} 

在本例中，PersonService:：addManager和PersonService：：removeManager的实现需要GroupMembershipService的实例才能完成其工作。如果没有依赖注入，传统的方法是在PersonService的构造函数中实例化一个新的GroupMembershipService，并在两个函数中使用该实例属性。但是，如果GroupMembershipService的构造函数有多个它需要的东西，或者更糟的是，需要在GroupMembershipServices上调用一些初始化“setter”，代码增长相当快，PersonService现在不仅依赖于GroupMembershipService，还依赖于GroupMembershipService所依赖的所有其他东西。此外，与GroupMembershipService的链接被硬编码到PersonService中，这意味着您不能为了测试目的而“虚拟”GroupMembershipServices，或者在应用程序的不同部分使用策略模式。

使用依赖注入，而不是在PersonService中实例化GroupMembershipService，您可以将其传递给PersonService构造函数，或者添加Property（getter和setter）来设置其本地实例，并与他们合作。这也意味着，任何属于GroupMembershipService的子类或实现GroupMembershipServices接口的内容都可以“注入”到PersonService中，PersonService不需要知道更改。

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

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

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

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

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

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

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

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）

摘自《扎实的Java开发人员：Java 7和多语言编程的关键技术》一书

DI是IoC的一种特殊形式，因此查找依赖项的过程是不受当前执行代码的直接控制。

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

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

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

依赖注入是与Spring框架相关概念的核心。在创建任何项目的框架时，Spring都可能发挥重要作用，而依赖注入就是其中之一。

实际上，假设在java中，您创建了两个不同的类，即类A和类B，并且无论类B中有什么函数，您都希望在类A中使用，所以此时可以使用依赖注入。在这里，您可以将一个类的对象放入另一个类中，就像您可以将整个类注入另一个类别中以使其可访问一样。通过这种方式可以克服依赖性。

依赖注入只是将两个类粘合在一起，同时保持它们的分离。