設計模式六大原則

@(0.05@設計模式)[設計模式|代碼規範|筆記--大話設計模式]

設計模式六大原則

1、面向對象設計六大原則

面向對象的關鍵在於封裝，封裝好了才能很好的複用，達到單一職責和開放擴展、封閉更改的效果。

一、單一職責原則

就一個類而言, 應該僅有一個引發它變化的緣由. 增長功能不該該修改已有的代碼, 避免修改出錯及重複測試.
若是你可以想到多於一個的動機去改變一個類,那麼這個類就是具備多於一個的職責, 應該考慮類的職責分離.

二、里氏代換原則

父類型能夠被子類型替換,程序行爲不發生變化. 這樣父類才能真正的被複用, 而子類也可以在父類的基礎上增長新的行爲.
里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。它包含如下4層含義：

• 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 子類中能夠增長本身特有的方法。
• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

三、依賴倒轉原則(面向對象設計的標誌)

1. 高層模塊不該該依賴底層模塊. 兩個都應該依賴抽象.
2. 抽象不該該依賴細節, 細節應該依賴抽象.

依賴倒轉就是誰也不依賴誰,除了約定的接口,你們均可以靈活自如.
程序中全部的依賴關係都是終止於抽象類或者接口,那就是面向對象的設計,反之就是過程化的設計.
在實際編程中，咱們通常須要作到以下3點：

• 低層模塊儘可能都要有抽象類或接口，或者二者都有。
• 變量的聲明類型儘可能是抽象類或接口。
• 使用繼承時遵循里氏替換原則。

依賴倒置原則的核心就是要咱們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。傳遞依賴關係有三種方式，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞.

四、接口隔離原則

定義：客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。
接口隔離原則的含義是：創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用。
不少人會覺的接口隔離原則跟以前的單一職責原則很類似，其實否則。其一，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離。其二，單一職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序總體框架的構建。
採用接口隔離原則對接口進行約束時，要注意如下幾點：

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

運用接口隔離原則，必定要適度，接口設計的過大或太小都很差。設計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這一原則。

五、迪米特法則(最少知識原則)

定義：一個對象應該對其餘對象保持最少的瞭解。
問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。
若是兩個類沒必要彼此直接通訊,那麼這兩個類就不該當發生直接的相互做用. 若是其中一個類須要調用另外一個類的某一個方法的話, 能夠經過第三者轉發這個調用.
前提：在類的設計上，每個類都應當儘可能下降成員的訪問權限。

六、開放-封閉原則

定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
問題由來：在軟件的生命週期內，由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使咱們不得不對整個功能進行重構，而且須要原有代碼通過從新測試。
解決方案：當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。

設計類時, 儘可能讓這個類是足夠好,寫好了就不要去修改,若是新需求來,增長一些類就完事,原來的代碼能不動就不動.
設計人員須要猜想出最有可能發生的變化種類,而後構造抽象來隔離那些變化.
發生小的變化時，就要及時去想辦法應對發生更大變化的可能，重構修改同一處代碼時要一次搞定，同一個地方不要修改2次。

開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我「你進行設計的時候必定要遵照開閉原則」，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。

在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的「平均得分」，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。

其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。

說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：

• 單一職責原則告訴咱們實現類要職責單一；
• 里氏替換原則告訴咱們不要破壞繼承體系；
• 依賴倒置原則告訴咱們要面向接口編程；
• 接口隔離原則告訴咱們在設計接口的時候要精簡單一；
• 迪米特法則告訴咱們要下降耦合。
• 而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。

最後說明一下如何去遵照這六個原則。對這六個原則的遵照並非是和否的問題，而是多和少的問題，也就是說，咱們通常不會說有沒有遵照，而是說遵照程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是同樣，制定這六個原則的目的並非要咱們刻板的遵照他們，而須要根據實際狀況靈活運用。對他們的遵照程度只要在一個合理的範圍內，就算是良好的設計。

參考文獻 :

• 設計模式六大原則
• 《大話設計模式》