之前一直斷斷續續的在看《設計模式之禪》，但是一段時間不接觸便漸漸對一些概念性的東西模糊了，再回過頭看來則會耗時耗力，畢竟設計模式這種東西猶如滴水穿石需持之以恒，結合實際開發才能慢慢的爛熟于心，所以決定將常用設計模式的精華部分摘記下來。下面以設計模式的六大原則開始，一一記之，后面會根據筆記作一個目錄匯總。

設計模式中六大原則

• 開閉原則(OCP)

• 職責單一原則(SRP)

• 里氏替換原則(LSP)

• 依賴倒置原則(DIP)

• 接口隔離原則(ISP)

• 合成復用原則(CRP)

• 迪米特法則(LOD)

Open Close Principle

OCP原則(開閉原則):一個軟件實體如類、模塊和函數等應該對拓展開發，對修改關閉。

注意

開閉原則對拓展開放，對修改關閉，并不意味這不做任何的修改，低層次模塊的變化，必然要有高層模塊進行耦合，否則就是一個孤立無意義的代碼片段。

在業務規則改變的情況下高層模塊必須有部分改變以適應新業務，改變要盡量地少，防止變化風險的擴散。 -秦小波 《設計模式之禪》

Single Responsibility Principle

SRP原則(職責單一原則):應該有且只有一個原因引起類的變更。

注意

單一原則的職責劃分需要根據具體場景和項目業務邏輯來進行判斷。

Liskov Substitution Principle

OCP原則(里氏替換原則)：所有引用基類的地方必須能透明地使用其子類的對象。

通俗點講：只要父類能出現的地方子類就可以出現，而且替換為子類也不產生任何異常錯誤，反之則不然。這主要體現在，我們經常使用抽象類/基類做為方法參數，具體使用哪個子類作為參數傳入進去，由調用者決定。

通俗點講，該原則包含以下幾點要素

• 子類必須完全實現父類的方法

• 子類可以有自己獨有的屬性和方法

• 覆蓋或者實現父類方法時，參數可以被放大。即父類的某個方法參數為HashMap時，子類參數可以是HashMap，也可以是Map或者更大

• 覆蓋或者實現父類的方法時，返回結果可以被縮小。即父類的某個方法返回類型是Map，子類可以是Map，也可以是HashMap或者更小

Dependence Inversion Principle

DIP原則(依賴倒置原則):抽象不應該依賴具體細節，而應該具體細節依賴于抽象，高層模塊不應該依賴底層模塊。

• 底層模塊：不可分割的原子邏輯就是低層模塊

• 高層模塊：低層模塊的組裝合成后就是高層模塊

• 抽象:Java中體現為基類、抽象類、接口，而不單指抽象類

• 細節:體現為子類、實現類

通俗點講，該原則包含以下幾點要素

• 模塊間的依賴應該通過抽象發生，具體實現類之間不應該建立依賴關系

• 接口或者抽象類不依賴于實現類，否則就失去了抽象的意義

• 實現類依賴于接口或者抽象類

• 修改properties等文本配置文件，不破壞依賴倒置原則

總結起來，一句話：“面向接口編程”。

Interface-Segregation Principle

ISP原則(接口隔離原則)：客戶端不依賴它不需要的接口；類間的依賴應該建立在最小的接口。

通俗點講：使用接口時應該建立單一接口，不要建立臃腫龐大的接口，盡量給調用者提供專門的接口，而非多功能接口。(類似職責單一原則，一個接口負責單個模塊或業務)

Composite Reuse Principle

CRP原則(合成復用原則)：盡量使用對象組合，而不是繼承來達到復用的目的。合成復用原則又稱為組合/聚合復用原則。

Low of Demeter

LOD法則(迪米特法則):又稱最小知識原則(Least Knowledge Principle,LKP),一個對象應該對其他對象有最少的了解。

該原則包含以下幾點要素

• 只和朋友類交流：只耦合該耦合的類

• 朋友間也是有距離的：減少不該public的方法，向外提供一個簡潔的訪問

• 自家的方法就自己創建：只要該方法不會增加內部的負擔，也不會增加類間耦合

通俗點講：一個類應該對自己需要耦合或者調用的類知道越少越好，被耦合或者調用的類內部和我沒有關系，我不需要的東西你就別public了吧。

七種常用面向對象設計原則，如下表所示：

本文章做筆記之用，本文出處：作者xiong_it ，地址：http://blog.csdn.net/xiong_it