每一个基于java的应用程序都有一个共同工作来展示给用户看到的内容作为工作的应用几个对象。当编写一个复杂的Java应用程序，应用程序类应该尽可能独立其他Java类来增加重复使用这些类，并独立于其他类别的测试它们，而这样做单元测试的可能性。依赖注入（或有时称为布线）有助于粘合这些类在一起，同时保持他们的独立。

考虑有其中有一个文本编辑器组件的应用程序，要提供拼写检查。标准的代码将看起来像这样：

 
public class TextEditor {
   private SpellChecker spellChecker;
   public TextEditor() {
      spellChecker = new SpellChecker();
   }
}

我们在这里所做的就是创建文本编辑和拼写检查之间的依赖性。在控制方案中的反转，我们反而会做这样的事情：

public class TextEditor {
   private SpellChecker spellChecker;
   public TextEditor(SpellChecker spellChecker) {
      this.spellChecker = spellChecker;
   }
}

在这里，文本编辑不应该担心拼写检查落实。拼写检查器将独立实施，将提供给文本编辑在文本编辑实例化的时候，这整个过程是由Spring框架的控制。

在这里，我们已经删除从文本编辑的全面控制，并保持它在其他地方（即XML配置文件）和依赖性（即类拼写检查）被注入到类文本编辑通过类构造函数。因此，流程控制已经“倒”通过依赖注入（DI），因为已经有效地委派依赖一些外部系统。

依赖注入的第二种方法是通过文本编辑类，我们将创建拼写检查实例的setter方法​​，该实例将被用来调用setter方法​​来初始化文本编辑的属性。

因此，DI主要有两种变体和下面的两个子章将涵盖两者结合实例：

S.N.	依赖注入类型及说明
1	基于构造函数的依赖注入 当容器调用类的构造函数有多个参数，每个代表在其他类中的构造函数依赖关系为基础的DI来完成。
2	基于setter方法的依赖注入 基于setterDI由容器调用setter方法​​对你的bean调用无参构造器或无参static工厂方法实例化bean之后完成的。

你可以混合两种，构造型和基于setter方法DI，但它是拇指使用构造函数的参数进行强制依赖和setter可选依赖的一个很好的规则。

代码是清洁器与DI原理，当对象被提供有它们的依赖性的去耦效果更明显。对象不查询它的依赖，以及不知道的依赖性的位置或类，而一切都由Spring框架关照。

纠错/补充 收藏