設計模式-6大設計原則

單一職責原則（SRP:Single Responsibility Principle）

定義：應該有且僅有一個緣由引發類的變動。

優勢：

• 類的複雜性下降；
• 可讀性提升；
• 可維護性提升；
• 變動引發的風險下降。

建議：接口必定要作到單一職責，類的設計儘可能作到只有一個緣由引發變化。

里氏替換原則（LSP:Liskov Substitution Principle）

定義：全部引用基類的地方必須能透明地使用其子類對象。

四層含義：

• 子類必須徹底實現父類的方法
• 子類能夠有本身的個性
• 覆蓋或實現父類的方法時輸入參數能夠被放大（子類參數是父類參數的基類）注：使用此規則重載父類函數，避免替換後調用子類方法，而不符合用戶預期
• 覆蓋或實現父類的方法時輸出參數能夠被縮小（子類返回值是父類返回值的派生類）注：參數列表相同時使用此規則構成重寫，符合預期；不一樣時構成重載，同上

建議：

類中調用其餘類時，務必使用父類或接口；不然說明違背了此原則。

若子類不能完整地實現父類的方法，則建議斷開父子繼承關係，採用依賴、彙集、組合等關係替代繼承。

 

依賴倒置原則（DIP:Dependence Inversion Principle）

三層含義：

• 模塊間的依賴經過抽象產生，實現類之間不發生依賴關係，其依賴是經過接口或抽象類產生的；
• 接口或抽象類不依賴於實現類；
• 實現類依賴接口或抽象類。

簡而言之：面向接口編程

抽象是對實現的約束，對依賴者而言，也是一種契約，目的是保證全部細節不脫離契約的範疇。

依賴的三種寫法：

1. 構造函數傳遞依賴對象（構造函數注入）
2. Setter方法傳遞依賴對象（Setter依賴注入）
3. 接口聲明依賴對象（接口注入）

建議：

• 每一個類儘可能有接口或抽象類
• 變量的表面類型儘可能是接口或抽象類
• 任何類都不該該從具體類派生
• 儘可能不要覆寫基類的方法
• 結合里氏替換原則使用

關於【倒置】：

「正置」：面向實現編程，開車依賴車，使用電腦依賴電腦。

根據系統設計的須要產生了抽象間的依賴，替代了人們傳統思惟中事務間的依賴，「倒置」就是從這裏產生的。

 

接口隔離原則(Interface Segregation Principle, ISP)

 定義：客戶端不該該依賴它不須要的接口。一個類對另外一個類的依賴應該創建在最小的接口上。（接口儘可能細化，同時接口中的方法儘可能少。）

 

四層含義：

• 接口要儘可能小：根據接口隔離原則拆分接口時，首先必須知足單一職責原則。
• 接口要高內聚：減小對外的交互，儘可能少公佈public方法。
• 定製服務：只提供訪問者須要的方法
• 接口設計是有限度的：接口設計注意適度，控制粒度與複雜度的平衡

 

迪米特法則（Law of Demeter,LoD/Least Knowledge Principle,LKP）

 

 定義：一個對象應該對其餘對象有最少的瞭解。

 

四層含義：

• 只和朋友交流：耦合的關係-組合、聚合、依賴等（方法實現時儘可能不引入一個類中不存在的對象）
• 朋友間也是有距離的：合理運用封裝性，封裝過分細化的接口做爲public方法暴露給朋友
• 是本身的就是本身的：若是一個方法能夠放在本類中，既不增長類間關係，也不對本類產生負面影響，那就放在本類中。
• 謹慎使用Serializable(序列化)

核心：

類間解耦，弱耦合。但過分使用會產生大量中轉或跳轉類，需反覆權衡找到平衡點，跳轉次數儘可能控制在兩次之內。

 

開閉原則（Open Closed Principle, OCP）

 定義：軟件中的對象（類，模塊，函數等等）應該對於擴展是開放的，可是對於修改是封閉的。

 

優勢：

• 提升複用性
• 提升可維護性
• 面向對象開發的要求

 

如何使用

1.  抽象約束：不容許出現抽象類中不存在的public方法；參數類型、引用對象儘可能使用抽象類，而不是實現類；抽象層儘可能保持穩定。
2. 元數據控制模塊行爲：從文件或數據庫中獲取元數據
3. 制定項目章程
4. 封裝變化：將相同的變化封裝到一個抽象類中；將不一樣的變化封裝到不一樣的抽象類中。

 總結

SRP:單一職責原則

OCP:開閉原則

LSP:里氏替換原則

LoD:迪米特法則

ISP:接口隔離原則

DIP:依賴倒置原則

將六大原則首字母連接，就是SOLID(穩定的)，創建穩定、靈活、健壯的設計，開閉原則是其餘5大原則的精神領袖。

開閉原則是一個終極目標，任何人都沒法百分百作到，咱們只是儘可能去朝這個目標去作，實際工做時也要結合具體狀況。

 

 

參考文獻：《設計模式之禪》--秦小波