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

jianyuerensheng發表於2016-03-09

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之間依賴關係的管理。

相關文章