重溫設計模式之軟體設計原則 依賴倒置原則

2021-10-09 12:56:23 字數 2281 閱讀 9509

依賴倒置原則(dependence inversion principle):

1、高層模組不應該依賴底層模組,二者都應該依賴抽象。

2、抽象不應該依賴細節,細節應該依賴抽象。

3、依賴倒置的中心思想是面向介面程式設計。

4、依賴倒置原則是基於這樣的設計理念:相對於細節的多變性,抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎搭建的架構要穩定的多。

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

先上類圖:

兩個介面:idriver和icar 分別定義了司機和汽車的各個職能,司機就是駕駛汽車,必須實現driver方法,其實現過程如**清單如下:

package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:33

*/public

inte***ce

idriver

介面只是乙個抽象化的概念,是對一類事物的最抽象描述,具體的實現**由相應的實現類來完成,driver實現**如下:

package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:35

*/public

class

driver

implements

idriver

}

在idriver中,通過傳入icar介面實現了抽象之間的依賴關係,driver實現類也傳入了icar 介面,至於到底是哪個型號的car,需要在高層模組中宣告。icar及其兩個實現類的實現過程**如下:

package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:33

*/public

inte***ce

icar

----

----

----

----

----

----

----

----

----

----

----

----

package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:36

*/public

class

bmwimplements

icar}--

----

----

----

----

----

----

----

----

--package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:37

*/public

class

benz

implements

icar

}

在業務場景中,我們貫徹「抽象不應該依賴細節」,也就是我們認為抽象(icar介面)不依賴bmw和benz兩個實現類(細節),因此在高層次的模組中應用都是抽象,client的實現 過程如**清單如下:

package com.yuqingit.pattern2;

/** * @version v1.0

* @description:

* @author: yuqing

* @date: 2020/9/17 11:46

*/public

class

client

}

軟體設計原則 依賴倒置原則

依賴倒置原則 dependence inversion principle,dip 高層模組不應該依賴底層模組,二者都應該依賴其抽象.抽象不應該依賴細節,細節應該依賴抽象.new 乙個小明 public class xiaoming public void studyartscourse 呼叫一下 ...

軟體設計原則 依賴倒轉原則

高層模組不應該依賴低層模組,兩者都應該依賴其抽象 抽象不應該依賴細節,細節應該依賴抽象。簡單的說就是要求對抽象進行程式設計,不要對實現進行程式設計,這樣就降低了客戶與實現模組間的耦合。例 組裝電腦 現要組裝一台電腦,需要配件cpu,硬碟,記憶體條。只有這些配置都有了,計算機才能正常的執行。選擇cpu...

設計模式 軟體設計原則

軟體設計六大原則 一 單一職責原則 srp 意思是就乙個類而言只有乙個改變類的起因和動機 遵循單一職責 1.可以降低類的複雜度,乙個類只負責一項職責,其邏輯肯定要比負責多項職責簡單的多 2.提高類可維護性,系統的可擴充套件性 3.變更引起的風險降低,當修改乙個功能時,可以顯著降低對其他功能的影響。二...