以上所有答案都很好，我的目的是用一种简单的方式解释这个概念，这样任何没有编程知识的人都可以理解这个概念

依赖注入是帮助我们以更简单的方式创建复杂系统的设计模式之一。

我们可以在日常生活中看到这种模式的广泛应用。其中一些例子是录音机、VCD、CD驱动器等。

上图是20世纪中期的便携式磁带录音机。来源

录音机的主要目的是记录或重放声音。

在设计系统时，需要一个卷轴来录制或播放声音或音乐。设计该系统有两种可能性

我们可以把卷轴放在机器里我们可以为卷轴提供一个可以放置的钩子。

如果我们使用第一个，我们需要打开机器来更换卷轴。如果我们选择第二种方式，即为卷轴设置挂钩，那么通过改变卷轴，我们可以获得播放任何音乐的额外好处。并且还将功能减少到只播放卷轴中的任何内容。

类似地，依赖注入是将依赖性外部化以仅关注组件的特定功能的过程，以便独立组件可以耦合在一起形成一个复杂的系统。

我们通过使用依赖注入获得的主要好处。

高内聚力和松耦合。外部化依赖，只关注责任。将事物作为组件，并结合起来形成具有高性能的大型系统。它有助于开发高质量的组件，因为它们是独立开发的，并且经过了适当的测试。如果一个组件出现故障，用另一个组件替换它会有帮助。

如今，这些概念构成了编程界众所周知的框架的基础。Spring Angular等是基于这一概念构建的著名软件框架

依赖注入是一种模式，用于创建其他对象依赖的对象实例，而在编译时不知道将使用哪个类来提供该功能，或者简单地将财产注入对象的方法称为依赖注入。

依赖注入示例

以前我们编写的代码是这样的

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

通过依赖注入，依赖注入器将为我们完成实例化

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 
   
  dependentObject.someMethod();
}

你也可以阅读

控制反转与依赖注入的区别

依赖注入（DI）是设计模式中的一种，它使用了OOP的基本特性——一个对象与另一个对象之间的关系。虽然继承继承一个对象以实现更复杂和更具体的另一个对象，但关系或关联只需使用属性从一个对象创建指向另一对象的指针。DI的功能与OOP的其他特性相结合，如接口和隐藏代码。假设图书馆里有一个客户（订阅者），为了简单起见，他只能借一本书。

书本界面：

package com.deepam.hidden;

public interface BookInterface {

public BookInterface setHeight(int height);
public BookInterface setPages(int pages);   
public int getHeight();
public int getPages();  

public String toString();
}

接下来我们可以有很多种书；其中一种类型是虚构：

package com.deepam.hidden;

public class FictionBook implements BookInterface {
int height = 0; // height in cm
int pages = 0; // number of pages

/** constructor */
public FictionBook() {
    // TODO Auto-generated constructor stub
}

@Override
public FictionBook setHeight(int height) {
  this.height = height;
  return this;
}

@Override
public FictionBook setPages(int pages) {
  this.pages = pages;
  return this;      
}

@Override
public int getHeight() {
    // TODO Auto-generated method stub
    return height;
}

@Override
public int getPages() {
    // TODO Auto-generated method stub
    return pages;
}

@Override
public String toString(){
    return ("height: " + height + ", " + "pages: " + pages);
}
}

现在，用户可以与图书建立关联：

package com.deepam.hidden;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class Subscriber {
BookInterface book;

/** constructor*/
public Subscriber() {
    // TODO Auto-generated constructor stub
}

// injection I
public void setBook(BookInterface book) {
    this.book = book;
}

// injection II
public BookInterface setBook(String bookName) {
    try {
        Class<?> cl = Class.forName(bookName);
        Constructor<?> constructor = cl.getConstructor(); // use it for parameters in constructor
        BookInterface book = (BookInterface) constructor.newInstance();
        //book = (BookInterface) Class.forName(bookName).newInstance();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return book;
}

public BookInterface getBook() {
  return book;
}

public static void main(String[] args) {

}

}

这三个类都可以隐藏起来，以便实现自己的功能。现在我们可以将此代码用于DI：

package com.deepam.implement;

import com.deepam.hidden.Subscriber;
import com.deepam.hidden.FictionBook;

public class CallHiddenImplBook {

public CallHiddenImplBook() {
    // TODO Auto-generated constructor stub
}

public void doIt() {
    Subscriber ab = new Subscriber();

    // injection I
    FictionBook bookI = new FictionBook();
    bookI.setHeight(30); // cm
    bookI.setPages(250);
    ab.setBook(bookI); // inject
    System.out.println("injection I " + ab.getBook().toString());

    // injection II
    FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set
    System.out.println("injection II " + ab.getBook().toString());      
}

public static void main(String[] args) {
    CallHiddenImplBook kh = new CallHiddenImplBook();
    kh.doIt();
}
}

如何使用依赖注入有许多不同的方法。可以将它与Singleton等结合起来，但基本上它只是通过在另一个对象内创建对象类型的属性来实现的关联。它的有用性是唯一的，也是唯一的特点，我们应该反复编写的代码总是为我们准备好并做好准备。这就是为什么DI如此紧密地与控制反转（IoC）绑定，这意味着我们的程序将控制传递给另一个正在运行的模块，该模块将bean注入到我们的代码中。（可以被注入的每个对象都可以被签名或被认为是一个Bean。）例如，在Spring中，它是通过创建和初始化ApplicationContext容器来完成的，这对我们来说很有用。我们只需在代码中创建Context并调用初始化Bean。此时注射已自动完成。

我想既然每个人都为DI写过文章，让我问几个问题。。

当您有一个DI配置，其中所有实际实现（而不是接口）都将被注入到一个类中（例如控制器的服务），为什么这不是某种硬编码？如果我想在运行时更改对象怎么办？例如，我的配置已经表明，当我实例化MyController时，为FileLogger注入ILogger。但我可能想注入DatabaseLogger。每次我想更改AClass需要的对象时，我都需要查看两个地方——类本身和配置文件。这是如何让生活更轻松的？如果没有注入Aproperty的AClass，是否更难模拟？回到第一个问题。如果使用new object（）不好，我们为什么要注入实现而不是接口？我想你们很多人都在说我们实际上是在注入接口，但配置要求您指定接口的实现。。不在运行时。。它在编译时是硬编码的。

这是基于@Adam N发布的答案。

为什么PersonService不再需要担心GroupMembershipService？您刚才提到了GroupMembership依赖于多个东西（对象/财产）。如果PService中需要GMService，您应该将其作为属性。不管你是否注射，你都可以模仿它。我唯一希望它被注入的时候是GMService是否有更具体的子类，这在运行时之前你不会知道。然后您需要注入子类。或者如果您想将其用作单例或原型。老实说，配置文件中的所有内容都是硬编码的，包括它将在编译时为类型（接口）注入的子类。

编辑

Jose Maria Arranz对DI的美好评论

DI通过消除确定依赖方向和编写任何粘合代码的任何需要来提高内聚性。

错误。依赖关系的方向是XML形式或注释，依赖关系是以XML代码和注释的形式编写的。XML和注释是源代码。

DI通过使您的所有组件模块化（即可更换）并具有相互定义良好的接口来减少耦合。

错误。您不需要DI框架来构建基于接口的模块化代码。

关于可替换：使用非常简单的.properties存档和Class.forName，您可以定义哪些类可以更改。如果代码的任何类都可以更改，Java不适合您，请使用脚本语言。顺便说一句：不重新编译就不能更改注释。

在我看来，DI框架只有一个原因：锅炉板减少。有了一个做得好的工厂系统，您可以像首选的DI框架一样做得更好、更可控、更可预测，DI框架可以减少代码（XML和注释也是源代码）。问题是这种锅炉板减少在非常简单的情况下是真实的（每个类一个实例以及类似的情况），有时在现实世界中，选择适当的服务对象不像将类映射到单个对象那样容易。

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

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

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

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

什么是依赖注入？

依赖注入（DI）意味着分离彼此依赖的对象。假设对象A依赖于对象B，因此想法是将这些对象彼此分离。我们不需要使用new关键字对对象进行硬编码，而是在运行时共享对对象的依赖关系，而不管编译时间如何。如果我们谈论

依赖注入在Spring中的工作原理：

我们不需要使用new关键字硬编码对象，而是在配置文件中定义bean依赖关系。弹簧容器将负责连接所有部件。

控制反转（IOC）

IOC是一个通用概念，可以用多种不同的方式表达，依赖注入是IOC的一个具体例子。

两种类型的依赖注入：

构造器注入沉淀剂注入

1.基于构造函数的依赖注入：

当容器调用具有多个参数的类构造函数时，就完成了基于构造函数的DI，每个参数表示对其他类的依赖。

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2.基于Setter的依赖注入：

基于Setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean上的Setter方法来实现的。

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

注：对于强制依赖项使用构造函数参数，对于可选依赖项使用setter，这是一个很好的经验法则。注意，如果我们在setter上使用基于@Required的注释，则可以将setter作为必需的依赖项。