設計模式六大原則——簡單複習

設計模式的原則單一職責原則

單一職責，每個類只負責一個功能，或者每個類只負責一個職責，這樣需要修改的時候，不會牽動太多聯絡，

裡氏替換原則

定義1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程式 P 在所有的對象 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼類型 T2 是類型 T1 的子類型。

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

 

 

這裡主要說的父類和子類的關係，當子類繼承父類時，遵循以下規則會減少出錯的機率：

1、子類繼承父類時，不要重寫父類已經實現的方法，子類可以添加自己新的方法

2、如果子類需要重寫父類的方法時，子類方法的形參必須必父類的形參要更寬鬆，並且子類的傳回值要比父類更詳細，更嚴格

3、子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法

 

依賴導致原則

定義：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成。這種情境下，類A一般是高層模組，負責複雜的商務邏輯；類B和類C是低層模組，負責基本的原子操作；假如修改類A，會給程式帶來不必要的風險。

解決方案：將類A修改為依賴介面I，類B和類C各自實現介面I，類A通過介面I間接與類B或者類C發生聯絡，則會大大降低修改類A的幾率。

         依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。在java中，抽象指的是介面或者抽象類別，細節就是具體的實作類別，使用介面或者抽象類別的目的是制定好規範和契約，而不去涉及任何具體的操作，把展現細節的任務交給他們的實作類別去完成。

1、低層模組盡量都要有抽象類別或介面，或者兩者都有。

2、變數的宣告類型盡量是抽象類別或介面。

3、使用繼承時遵循裡氏替換原則。

介面隔離原則

定義：用戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。

問題由來：類A通過介面I依賴類B，類C通過介面I依賴類D，如果介面I對於類A和類B來說不是最小介面，則類B和類D必須去實現他們不需要的方法。

解決方案：將臃腫的介面I拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則。

舉例來說明介面隔離原則：

用最少的介面，解決多的事情，介面的多少需要實際經驗的支援，一般都以細分為主

 

迪米特法則

定義：一個對象應該對其他對象保持最少的瞭解。

問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。

解決方案：盡量降低類與類之間的耦合。

         自從我們接觸編程開始，就知道了軟體編程的總的原則：低耦合，高內聚。無論是面向過程編程還是物件導向編程，只有使各個模組之間的耦合盡量的低，才能提高代碼的複用率。低耦合的優點不言而喻，但是怎麼樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。

 

開閉原則

定義：一個軟體實體如類、模組和函數應該對擴充開放，對修改關閉。

問題由來：在軟體的生命週期內，因為變化、升級和維護等原因需要對軟體原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。

解決方案：當軟體需要變化時，盡量通過擴充軟體實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。

在遵守以上五個原則的同時，已經遵守了開閉原則，反之則沒有。

開閉原則無非就是想表達這樣一層意思：用抽象構建架構，用實現擴充細節。