依賴注入

每個基于應用程序的 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 = new SpellChecker();
   }
}

在這里，TextEditor 不應該擔心 SpellChecker 的實現。SpellChecker 將會獨立實現，并且在 TextEditor 實例化的時候將提供給 TextEditor，整個過程是由 Spring 框架的控制。

在這里，我們已經從 TextEditor 中刪除了全面控制，并且把它保存到其他地方（即 XML 配置文件），且依賴關系（即 SpellChecker 類）通過類構造函數被注入到 TextEditor 類中。因此，控制流通過依賴注入（DI）已經“反轉”，因為你已經有效地委托依賴關系到一些外部系統。

依賴注入的第二種方法是通過 TextEditor 類的 Setter 方法，我們將創建 SpellChecker 實例，該實例將被用于調用 setter 方法來初始化 TextEditor 的屬性。

因此，DI 主要有兩種變體和下面的兩個子章將結合實例涵蓋它們：

你可以混合這兩種方法，基于構造函數和基于 setter 方法的 DI，然而使用有強制性依存關系的構造函數和有可選依賴關系的 sette r是一個好的做法。

代碼是 DI 原理的清洗機，當對象與它們的依賴關系被提供時，解耦效果更明顯。對象不查找它的依賴關系，也不知道依賴關系的位置或類，而這一切都由 Spring 框架控制的。