設計模式 - 六大原則

1. 單一職責原則(SRP, Single Responsibility Principle)

核心思想

就一個類而言，應該僅有一個引發其變化的緣由。

問題描述

假若有類Class1完成兩個職責T一、T2，當職責T1或T2有變動須要修改時，有可能影響到該類的另外一個職責的正常工做。

具體描述

若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，致使其一個職責的變化將可能會影響到其它職責的完成(削弱或抑制這個類完成其它職責的能力)。這種耦合將致使設計變得脆弱，當變化發生時，設計會遭到意想不到的破壞。

好處

下降類的複雜性，提升可讀性、可維護性和擴展性，以及下降由於變動引發的風險。

注意

1. 軟件設計真正要作的許多內容，就是發現職責並把這些職責相互分離。
2. 單一職責提出了一個編程的標準，就是用「職責」和「變化」來衡量接口與類設計是否優良。但這二者都沒法直接度量，須要依據具體項目和環境。

2. 里氏代換原則(LSP, Liskov Substitution Principle)

核心思想

子類型必須可以替換掉它們的父類型(基類)。也就是在任意使用父類型的地方，能夠將這個父類型替換成其任意子類型。

具體描述

一個軟件實體，若是使用的是一個父類的話，那麼必定適用於其子類，並且它察覺不出父類對象和子類對象的區別。也就是在程序中，在使用父類的地方，將父類替換成其子類，程序的行爲沒有變化。 也正是這個原則，才使得面向對象的繼承複用成爲可能。只有子類能夠替換掉父類，軟件單位的功能不受影響時，父類才能真正被複用，而子類也可以在父類的基礎上增長新的行爲。

好處

加強了程序的健壯性，子類之間不會相互影響，增長新的子類，原有的子類仍正常工做。

注意

若是子類不能完整地實現父類的方法，或者父類中的某些方法在基類中已經發生「畸變」，則建議「斷開」使用父子繼承關係，而採用依賴、聚合、組合等關係。

3. 依賴倒轉原則(DIP,Dependence Inversion Principle)

核心思想

(依賴) 抽象不該該依賴細節，細節應該依賴於抽象。也就是要針對接口編程(核心)，而非針對實現編程。 (倒轉) 高層模塊不該依賴低層模塊，應該依賴於抽象。

• 高層模塊 -> 調用端
• 低層模塊 -> 具體實現類
• 抽象 -> 接口或抽象類
• 細節 -> 實現類

問題描述

假設一開始類A依賴與類B，如今要改成類A依賴於類C，那麼就須要改動類A的代碼。這裏的類A是高層模塊，類B和類C是低層模塊；高層模塊通常負責複雜的業務邏輯，底層模塊實現具體的原子操做。修改高層模塊會給程序帶來風險。

問題舉例

User模塊用來處理用戶數據，原先它依賴於SQLServer類，如今業務變更，要求使用MySQL類，你需在User模塊中修改全部使用SQLServer的地方。User模塊在這裏屬於高層模塊，SQLServer與MySQL類是低層模塊。

解決方法

對低層模塊進行抽象，高層模塊依賴於低層模塊的抽象。也就是對SQLServer類與MySQL類進行抽象，建立一個SQL接口或抽象類，User模塊依賴於這個SQL接口或抽象類進行編程。

其它描述

相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構穩定的多。

注意

在實際編程中，通常要作到：

1. 低層模塊儘可能要有抽象類或接口。
2. 變量的聲明類型應儘可能使用抽象類或接口名。
3. 使用繼承時，遵循里氏代換原則。

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

核心思想

客戶端不該該強行依賴它不須要的接口，類與類之間的依賴關係應該創建在最小的接口上。

思想描述

也就是在程序中，接口的方法應儘可能少，不要使接口過於臃腫，不要有不少不相關的邏輯。儘可能爲每一個類創建專用接口，而不是多個類使用同一個接口，致使這個接口中的方法不少。

注意

1. 接口儘可能小，可是有限度。 對接口進行細化能夠提升程序設計的靈活性，可是若是太小，將致使接口數量過多，增長了複雜度。
2. 提升內聚，減小對外交互。 使接口用最少的方法，完成最多的事情。
3. 爲依賴接口的類定製服務。 只暴露給調用類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。

5. 迪米特法則(LoD,Law of Demeter)

核心思想

類間解耦。

思想描述

也叫最少知識原則(LKP,Least Knowledge Principle)，若是兩個類沒必要彼此之間直接通訊，那麼這兩個類就不該該發生直接的相互做用。若是一個類須要調用另外一個類的方法，能夠經過第三者來轉發這個調用。 一個模塊設計的好壞，一個重要標誌就是該模塊在多大的程度上將本身內部的數據與實現有關的細節隱藏起來。信息的隱藏很是重要的緣由在於，它可使各個子系統之間解耦，從而容許它們獨立地被開發、優化、使用閱讀及修改。 迪米特法則首先強調的前提是，在類的設計上，每個類都應該儘可能下降成員的訪問權限。也就是儘可能使用private，不需讓其它類知道本身的屬性和行爲。 迪米特法則的根本思想是，強調了類之間的鬆耦合。類之間的耦合越弱，越利於複用。一個處於弱耦合的類被修改，不會對其有關的其它類有影響。 迪米特法則一般被描述爲：Only talk to your immediate friends(只和你最近的朋友進行交互)。每一個對象都會與其它對象之間有耦合關係，這種耦合關係就是這種「朋友」關係。耦合的方式有多種，如依賴、關聯、聚合、組合等，咱們稱出如今成員變量、方法參數、方法返回值中的類爲最近的朋友，而出如今局部變量中的類則不是最近的朋友。

示例

去店裏買東西，咱們將鈔票拿給收銀員，而非是將錢包丟給收銀員。

相關設計模式

1. 外觀模式(Facade)
2. 中介者模式(Mediator)

注意

程序設計的總原則就是：高內聚、低耦合。

6. 開放-封閉原則(OCP,Open Close Principle)

核心思想

軟件實體(類、模塊、函數等)應該可以擴展，但不能夠修改。

具體描述

儘可能經過擴展軟件實體來解決業務需求的變更，而不是修改已有代碼。 兩個特徵：

1. 對於擴展是開放的(Open for extension)
2. 對於更改是封閉的(Close for modification)

注意

開放-封閉原則是面向對象設計的核心所在。 遵循這個原則能夠帶來面向對象技術的巨大好處：可維護、可擴展、可複用、靈活性好。 應該僅對程序中出現頻繁變化的部分進行抽象，但決不要對每一個部分進行抽象。拒毫不成熟的抽象與抽象自己同樣重要。

總結

• 單一職責原則：實現類的職責要單一。
• 里氏代換原則：不要破壞繼承體系。
• 依賴倒轉原則：面向接口(抽象)編程。
• 接口隔離原則：接口設計須要精簡。
• 迪米特法則：下降類之間的耦合。
• 開閉原則(總綱)：對擴展開放，對修改關閉。

設計模式的6大原則，咱們能夠根據業務狀況靈活遵照，不能生搬硬套，過猶不及，只要是在一個合理的遵照程度上，就算是良好的設計。