我能想到的最好的类比是手术室中的外科医生和他的助手，在那里，外科医生是主要的人，他的助手在他需要时提供各种手术组件，以便外科医生能够专注于他最擅长的一件事（手术）。如果没有助手，外科医生每次需要时都必须自己取下部件。

简而言之，DI是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见额外责任（负担）的技术。

DI使您更接近单一责任（SR）原则，就像外科医生可以专注于外科手术一样。

何时使用DI：我建议在几乎所有的生产项目（小型/大型）中使用DI，尤其是在不断变化的业务环境中：）

原因：因为您希望代码易于测试、可模拟等，以便快速测试更改并将其推向市场。此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不这样做呢。

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

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

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

DI是真实对象之间实际交互的方式，而不需要一个对象负责另一个对象的存在。应平等对待对象。它们都是对象。任何人都不应该表现得像一个创造者。这就是你如何公正对待你的目标。

简单示例：

如果你需要医生，你只需去找一位（现有的）医生。你不会考虑从头开始创建一个医生来帮助你。他已经存在，他可能为你或其他对象服务。无论你（一个物体）是否需要他，他都有权存在，因为他的目的是为一个或多个物体服务。决定他的存在的是全能的上帝，而不是自然选择。因此，DI的一个优点是避免在整个宇宙（即应用程序）的生命周期中创建无用的冗余对象。

简单来说，依赖注入（DI）是消除不同对象之间的依赖关系或紧密耦合的方法。依赖注入为每个对象提供一个内聚行为。

DI是国际奥委会春季原则的实施，该原则说“不要打电话给我们，我们会打电话给你”。使用依赖注入程序员不需要使用new关键字创建对象。

对象一旦加载到Spring容器中，我们就可以在需要时重用它们，方法是使用getBean（StringbeanName）方法从Spring容器中获取这些对象。

依赖注入（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与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变，那就是测试。