Spring的依赖注入概述

以下内容引用自http://wiki.jikexueyuan.com/project/spring/dependency-injection.html：

每个基于Java应用程序都有几个对象，这些对象一起工作来呈现出终端用户所看到的工作的应用程序。当编写一个复杂的Java应用程序时，应用程序类应该尽可能独立于其他Java类来增加这些类重用的可能性，并且在做单元测试时，测试独立于其他类的独立性。依赖注入（或有时称为布线）有助于把这些类粘合在一起，同时保持他们独立。

假设你有一个包含文本编辑器组件的应用程序，并且你想要提供拼写检查。代码如下：

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

在这里我们所做的就是创建一个TextEditor和SpellChecker之间的依赖关系。在控制反转的场景中，代码变成了这样：

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

在这里，TextEditor不应该担心SpellChecker的实现。SpellChecker将会独立实现，并且在TextEditor实例化的时候将提供给TextEditor，整个过程是由Spring框架的控制。

在这里，我们已经从TextEditor中删除了全面控制，并且把它保存到其他地方（即XML配置文件），且依赖关系（即SpellChecker类）通过类构造函数被注入到TextEditor类中。因此，控制流通过依赖注入（DI）已经“反转”，因为你已经有效地委托依赖关系到一些外部系统。

依赖注入的第二种方法是通过TextEditor类的Setter方法，我们将创建SpellChecker实例，该实例将被用于调用setter方法来初始化TextEditor的属性。

因此，DI主要有两种形式的做法：

1. Constructor-based dependency injection（基于构造函数的依赖注入），当容器调用带有多个参数的构造函数类时，实现基于构造函数的DI，每个代表在其他类中的一个依赖关系。
2. Setter-based dependency injection（基于setter函数的依赖注入），基于setter方法的DI是通过在调用无参数的构造函数或无参数的静态工厂方法实例化bean之后容器调用beans的setter方法来实现的。

你可以混合这两种方法，基于构造函数和基于setter方法进行DI，然而使用有强制性依存关系的构造函数和有可选依赖关系的setter是一个好的做法。

代码是DI原理的清洗机，当对象与它们的依赖关系被提供时，解耦效果更明显。对象不查找它的依赖关系，也不知道依赖关系的位置或类，而这一切都由Spring框架控制的。