設計模式的六大原則之三(依賴倒置原則)

2021-09-30 00:21:30 字數 1679 閱讀 6007

核心思想:依賴於抽象(就是對介面程式設計,不要對實現程式設計)

高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。

以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。 

抽象指的是介面或者抽象類,細節就是具體的實現類,使用介面或者抽象類的目的是制定好規範和契約,而不去涉及任何具體的操作,把展現細節的任務交給他們的實現類去完成。

依賴倒置原則的核心思想是面向介面程式設計,我們依舊用乙個例子來說明面向介面程式設計比相對於面向實現程式設計好在什麼地方。

場景是這樣的,母親給孩子講故事,只要給她一本書,她就可以照著書給孩子講故事了。**如下:

class book

}class mother

}public class client

}

執行結果:

媽媽開始講故事 

很久很久以前有乙個阿拉伯的故事……

執行良好,假如有一天,需求變成這樣:不是給書而是給乙份報紙,讓這位母親講一下報紙上的故事,報紙的**如下:

class news*****

}

這位母親卻辦不到,因為她居然不會讀報紙上的故事,這太荒唐了,只是將書換成報紙,居然必須要修改mother才能讀。 

假如以後需求換成雜誌呢?換成網頁呢? 

還要不斷地修改mother,這顯然不是好的設計。 

原因就是mother與book之間的耦合性太高了,必須降低他們之間的耦合度才行。

我們引入乙個抽象的介面ireader。 

讀物,只要是帶字的都屬於讀物:

inte***ce ireader

mother類與介面ireader發生依賴關係,而book和news*****都屬於讀物的範疇, 

他們各自都去實現ireader介面,這樣就符合依賴倒置原則了,**修改為:

inte***ce ireader

class news***** : ireader

}class book : ireader

}class mother

}public class client

}

這樣修改後,無論以後怎樣擴充套件client類,都不需要再修改mother類了。 

這只是乙個簡單的例子,實際情況中,代表高層模組的mother類將負責完成主要的業務邏輯,一旦需要對它進行修改,引入錯誤的風險極大。 

所以遵循依賴倒置原則可以降低類之間的耦合性,提高系統的穩定性,降低修改程式造成的風險。 

採用依賴倒置原則給多人並行開發帶來了極大的便利,

比如上例中,原本mother類與book類直接耦合時,mother類必須等book類編碼完成後才可以進行編碼,因為mother類依賴於book類。 

修改後的程式則可以同時開工,互不影響,因為mother與book類一點關係也沒有。 

參與協作開發的人越多、專案越龐大,採用依賴導致原則的意義就越重大。 

現在很流行的tdd開發模式就是依賴倒置原則最成功的應用。

1.低層模組盡量都要有抽象類或介面,或者兩者都有。 

2.變數的宣告型別盡量是抽象類或介面。使用繼承時遵循黎克特制替換原則。 

3.依賴倒置原則的核心就是要我們面向介面程式設計,理解了面向介面程式設計,也就理解了依賴倒置。

六大原則之依賴倒轉 倒置 原則

package com.study public class dependencyinversion class email 1.優點 呼叫方式簡單 3.解決方法 引入乙個抽象的介面 ireceiver,表示接收者,這樣 person 類與介面 ireceiver 發生依賴 因為 email,wei...

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...