設計模式 七大設計原則(二)

2021-10-07 11:20:47 字數 4049 閱讀 9068

簡單介紹一下七大設計原則:

開閉原則:是所有物件導向設計的核心,對擴充套件開放,對修改關閉

依賴倒置原則:針對介面程式設計,依賴於抽象而不依賴於具體

單一職責原則:乙個介面只負責一件事情,只能有乙個原因導致類變化

介面隔離原則:使用多個專門的介面,而不是使用乙個總介面

迪公尺特法則(最少知道原則):只和朋友交流(成員變數、方法輸入輸出引數),不和陌生人說話,控制好訪問修飾符

黎克特制替換原則:子類可以擴充套件父類的功能,但不能改變父類原有的功能

合成復用原則:盡量使用物件組合(has-a)/聚合(contanis-a),而不是繼承關係達到軟體復用的目的

單一職責(****** responsibility pinciple,srp)是指不要存在多於乙個導致類變更 的原因。假設我們有乙個 class 負責兩個職責,一旦發生需求變更,修改其中乙個職責的邏輯**,有可能會導致另乙個職責的功能發生故障。這樣一來,這個 class 存在兩個導 致類變更的原因。如何解決這個問題呢?我們就要給兩個職責分別用兩個 class 來實現, 進行解耦。後期需求變更維護互不影響。這樣的設計,可以降低類的複雜度,提高類的 可讀性,提高系統的可維護性,降低變更引起的風險。總體來說就是乙個 class/inte***ce/method 只負責一項職責。

新建使用者資訊iuserinfo類:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:07

*/public inte***ce iuserinfo

使用者資訊維護類圖:

如果像這樣子來設計,即使是乙個初級程式設計師也可以看出這個解耦設計得有問題,使用者的屬性和使用者的行為沒有分離開。應該把使用者的資訊抽離成為乙個bo,把行為抽離成為乙個biz(業務邏輯)。然後我們修改這個介面。

建立iuserbo類:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:18

*/public inte***ce iuserbo

建立iuserbiz類:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:18

*/public inte***ce iuserbiz

職責劃分後的類圖:

我們將iuserinfo拆分為了iuserboiuserbiz。我們就實現了兩個類的單一職責,也就是讓引起他們變化原因只有一種,並且讓相關性強的內容聚合在乙個類內部。

但是,我們在實際開發中會專案依賴,組合,聚合這些關係,還有還有專案的規模,週期,技術人員的水平,對進度的把控,很多類都不符合單一職責。但是,我們在編寫**的過程,盡可能地讓介面和方法保持單一職責,對我們專案後期的維護是有很大幫助的。

介面隔離原則(inte***ce segregation principle, isp)是指用多個專門的介面,而不使 用單一的總介面,客戶端不應該依賴它不需要的介面。這個原則指導我們在設計介面時 應當注意一下幾點:

乙個類對一類的依賴應該建立在最小的介面之上。

建立單一介面,不要建立龐大臃腫的介面。

盡量細化介面,介面中的方法盡量少(不是越少越好,一定要適度)

介面隔離原則符合我們常說的高內聚低耦合的設計思想,從而使得類具有很好的可讀性、 可擴充套件性和可維護性。我們在設計介面的時候,要多花時間去思考,要考慮業務模型,包括以後有可能發生變更的地方還要做一些預判。所以,對於抽象,對業務模型的理解 是非常重要的。

下面我們來看一段**,寫乙個動物行為的抽象:

ianimal介面:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:56

*/public inte***ce ianimal

bird類實現:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:57

*/public class bird implements ianimal

public void fly()

public void swim()

}

dog類實現:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:57

*/public class dog implements ianimal

public void fly()

public void swim()

}

可以看出,birdswim()方法可能只能空著,dogfly()方法顯然不可能的。這時候,我們針對不同動物行為來設計不同的介面,分別設計ieatanimaliflyanimaliswimanimal介面,來看**:

ieatanimal介面:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:59

*/public inte***ce ieatanimal

iflyanimal介面:

/**

* @author eamon.zhang

* @date 2019-09-25 下午5:01

*/public inte***ce iflyanimal

iswimanimal介面:

/**

* @author eamon.zhang

* @date 2019-09-25 下午5:02

*/public inte***ce iswimanimal

dog只實現ieatanimaliswimanimal介面:

/**

* @author eamon.zhang

* @date 2019-09-25 下午4:57

*/public class dog implements ieatanimal,iswimanimal

public void swim()

}

來看下兩種類圖的對比,還是非常清晰明了的:

設計模式 七大設計原則

定義 應該有且只有乙個原因,引起類的變更 組合是一種強耦合關係,你我都有共同的生命週期,這種強耦合關係,不如直接使用介面實現 建議 介面一定要做到單一原則,類的設計盡量做到只有乙個原因引起變更 定義 所有使用父類的地方,必須能夠透明的使用其子類,反之不行 子類不能完整地實現父類的方法,或者父類的某些...

設計模式 七大設計原則(一)

簡單介紹一下七大設計原則 開閉原則 是所有物件導向設計的核心,對擴充套件開放,對修改關閉 依賴倒置原則 針對介面程式設計,依賴於抽象而不依賴於具體 單一職責原則 乙個介面只負責一件事情,只能有乙個原因導致類變化 介面隔離原則 使用多個專門的介面,而不是使用乙個總介面 迪公尺特法則 最少知道原則 只和...

七大設計原則

開閉原則 定義 乙個軟體實體如類 模組和函式應該對擴充套件開放 對修改關閉 用抽象構建框架,用實現擴充套件細節 優點 提高軟體系統的可復用性及可維護性 依賴倒置原則 定義 高層模組不應該依賴低層模組,二者都應該依賴其抽象 抽象不應該依賴細節,細節應該依賴抽象 針對介面程式設計,不要針對實現程式設計 ...