設計模式之依賴倒置原則含義及現實舉例

偶my耶的部落格發表於2015-04-02

所謂依賴倒置原則(Dependence Inversion Principle )就是要依賴於抽象,不要依賴於具體。簡單的說就是對抽象進行程式設計,不要對實現進行程式設計,這樣就降低了客戶與實現模組間的耦合。

程式導向的開發,上層呼叫下層,上層依賴於下層,當下層劇烈變化時,上層也要跟著變化,這就會導致模組的複用性降低而且大大提高了開發的成本。 物件導向的開發很好的解決了這個問題,一般的情況下抽象的變化概率很小,讓使用者程式依賴於抽象,實現的細節也依賴於抽象。即使實現細節不斷變化,只要抽象不變,客戶程式就不需要變化。這大大降低了客戶程式域實現細節的耦合度。

抽象不應該依賴細節,細節應該依賴於抽象。說白了,就是針對介面程式設計,不要針對實現程式設計。

依賴倒置原則包含三層含義:

1)高層模組不應該依賴低層模組,兩者都應該依賴其抽象;

2)抽象不應該依賴細節;

3)細節應該依賴抽象。

依賴倒置有三種方式來實現

1、通過建構函式傳遞依賴物件; 比如在建構函式中的需要傳遞的引數是抽象類或介面的方式實現。

2、通過setter方法傳遞依賴物件; 即在我們設定的setXXX方法中的引數為抽象類或介面,來實現傳遞依賴物件。

3、介面宣告實現依賴物件,也叫介面注入;

即在函式宣告中引數為抽象類或介面,來實現傳遞依賴物件,從而達到直接使用依賴物件的目的。

為方便理解,舉一些生活中的例子:

1、AGP插槽。主機板和顯示卡之間關係的抽象。主機板和顯示卡通常是使用AGP插槽來連線的,這樣,只要介面適配,不管是主機板還是顯示卡更換,都不是問題。

2、駕照。司機和汽車之間關係的抽象。有駕照的司機可以駕駛各種汽車。

3、電源插座。 設計模式中最能體現DIP原則的是抽象工廠模式。在抽象工廠模式中,工廠和產品都可以是抽象的,如果客戶要使用的話,只要關注於工廠和產品的介面即可,不必關注與工廠和產品的具體實現。

DIP對於並行開發的影響:兩個類之間有依賴關係,只要制定出他們之間的介面,就可以並行開發了。

備註: 1、什麼叫做高層模組依賴於底層模組?

程式導向的開發時,為了複用一些常用程式碼,通常會把這些程式碼寫成函式庫的形式。這樣,以後做新專案時,呼叫這些底層函式就可以了。這就叫做高層模組依賴於底層模組。 高層模組一般和業務邏輯相關,底層模組一般和具體實現相關。

2、何謂“倒置”?

這是因為傳統的軟體開發方法,如結構化的分析和設計,傾向於建立高層模組依賴於低層模組、抽象依賴於具體的軟體結構。實際上,這些方法的目標之一就是去定義描述上層模組如何呼叫低層模組的層次結構。所以,相對於傳統的過程化的方法通常所產生的那種依賴結構,一個設計良好的物件導向的程式中的依賴結構就是“被倒置”的。 來看一下那些依賴於低層模組的高層模組的含義。一個應用中的重要策略決定及業務模型正是在這些高層的模組中。也正是這些模型包含著應用的特性。但是,當這些模組依賴於低層模組時,低層模組的修改將會直接影響到它們,迫使它們也去改變。這種境況是荒謬的。應該是處於高層的模組去迫使那些低層的模組發生改變。應該是處於高層的模組優先於低層的模組。無論如何高層的模組也不應依賴於低層的模組。而且,我們想能夠複用的是高層的模組。通過子程式庫的形式,我們已經可以很好地複用低層的模組了。

當高層的模組依賴於低層的模組時,這些高層模組就很難在不同的環境中複用。但是,當那些高層模組獨立於低層模組時,它們就能很簡單地被複用了。這正是位於框架設計的最核心之處的原則。

相關文章