【Spring】Spring依賴注入與控制反轉理解

Spring是一個龐大的框架，封裝了很多成熟的功能，能夠讓我們無需重複造輪子；其次，它使用IOC進行依賴管理，利用JAVA的反射機制，將例項的初始化交給Spring，Spring可以通過配置檔案管理例項，我們就不用自己初始化例項啦。

有人會問 “那我們可以直接使用工廠模式呀。工廠模式也可以管理例項的初始化呀，為什麼一定要使用Spring呢？” 這是因為IOC是通過反射機制來實現的。當我們的需求出現變動時，工廠模式會需要進行相應的變化。但是IOC的反射機制允許我們不重新編譯程式碼，因為它的物件都是動態生成的。

一.什麼是依賴注入和控制反轉？

控制反轉：即IOC (Inversion of Control)，它把傳統上由程式程式碼直接操控的物件的呼叫權交給容器，通過容器來實現物件元件的裝配和管理。所謂的“控制反轉”概念就是對元件物件控制權的轉移，從程式程式碼本身轉移到了外部容器。

依賴注入：基本原則是：應用元件不應該負責查詢資源或者其他依賴的協作物件。配置物件的工作應該由IoC容器負責，“查詢資源”的邏輯應該從應用元件的程式碼中抽取出來，交給IoC容器負責。

依賴注入(Dependency Injection)和控制反轉(Inversion of Control)是同一個概念。
具體含義是:當某個角色(可能是一個Java例項，呼叫者)需要另一個角色(另一個Java例項，被呼叫者)的協助時，在 傳統的程式設計過程中，通常由呼叫者來建立被呼叫者的例項。但在Spring裡，建立被呼叫者的工作不再由呼叫者來完成，因此稱為控制反轉；建立被呼叫者例項的工作通常由Spring容器來完成，然後注入呼叫者，因此也稱為依賴注入。

二. 例項解釋

不管是依賴注入，還是控制反轉，都說明Spring採用動態、靈活的方式來管理各種物件。物件與物件之間的具體實現互相透明。在理解依賴注入之前，看如下這個問題在各種社會形態裡如何解決：一個人(Java例項，呼叫者)需要一把斧子(Java例項，被呼叫者)。

(1) 原始社會裡，幾乎沒有社會分工。需要斧子的人(呼叫者)只能自己去磨一把斧子(被呼叫者)。對應的情形為：Java程式裡的呼叫者自己建立被呼叫者。
這種情況下，Java例項的呼叫者建立被呼叫的Java例項，必然要求被呼叫的Java類出現在呼叫者的程式碼裡。無法實現二者之間的鬆耦合。

(2) 進入工業社會，工廠出現。斧子不再由普通人完成，而在工廠裡被生產出來，此時需要斧子的人(呼叫者)找到工廠，購買斧子，無須關心斧子的製造過程。對應Java程式的簡單工廠的設計模式。
這種情況下，呼叫者無須關心被呼叫者具體實現過程，只需要找到符合某種標準(介面)的例項，即可使用。此時呼叫的程式碼面向介面程式設計，可以讓呼叫者和被呼叫者解耦，這也是工廠模式大量使用的原因。但呼叫者需要自己定位工廠，呼叫者與特定工廠耦合在一起。

(3) 進入“按需分配”社會，需要斧子的人不需要找到工廠，坐在家裡發出一個簡單指令:需要斧子。斧子就自然出現在他面前。對應Spring的依賴注入。
這種情況下，呼叫者無須自己定位工廠，程式執行到需要被呼叫者時，系統自動提供被呼叫者例項。事實上，呼叫者和被呼叫者都處於Spring的管理下，二者之間的依賴關係由Spring提供。

三.總結：

所謂依賴注入，是指程式執行過程中，如果需要呼叫另一個物件協助時，無須在程式碼中建立被呼叫者，而是依賴於外部的注入。Spring的依賴注入對呼叫者和被呼叫者幾乎沒有任何要求，完全支援對POJO之間依賴關係的管理。