IOS設計模式六大法則

標籤：

設計模式的六大原則

單一職責原則

定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責

問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。

解決方案：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。

裡氏替換原則（Liskov Substitution Principle）

肯定有不少人跟我剛看到這項原則的時候一樣，對這個原則的名字充滿疑惑。其實原因就是這項原則最早是在1988年，由麻省理工學院的一位姓裡的女士（Barbara Liskov）提出來的。

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

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

問題由來：有一功能P1，由類A完成。現需要將功能P1進行擴充，擴充後的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障。

解決方案：當使用繼承時，遵循裡氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法。

         繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），實際上是在設定一系列的規範和契約，雖然它不強制要求所有的子類必須遵從這些契約，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而裡氏替換原則就是表達了這一層含義。

依賴倒置原則（Dependence Inversion Principle）

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

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

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

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

介面隔離原則（Interface Segregation Principle）

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

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

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

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

 

 

迪米特法則（Law Of Demeter）

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

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

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

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

         迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都盡量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何資訊。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每個對象都會與其他對象有耦合關係，只要兩個對象之間有耦合關係，我們就說這兩個對象之間是朋友關係。耦合的方式很多，依賴、關聯、組合、彙總等。其中，我們稱出現成員變數、方法參數、方法傳回值中的類為直接的朋友，而出現在局部變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變數的形式出現在類的內部。

開閉原則（Open Close Principle）

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

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

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

         開閉原則是物件導向設計中最基礎的設計原則，它指導我們如何建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的一個了，它只告訴我們對擴充開放，對修改關閉，可是到底如何才能做到對擴充開放，對修改關閉，並沒有明確的告訴我們。以前，如果有人告訴我“你進行設計的時候一定要遵守開閉原則”，我會覺的他什麼都沒說，但貌似又什麼都說了。因為開閉原則真的太虛了。

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

         其實筆者認為，開閉原則無非就是想表達這樣一層意思：用抽象構建架構，用實現擴充細節。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟體架構的穩定。而軟體中易變的細節，我們用從抽象派生的實作類別來進行擴充，當軟體需要發生變化時，我們只需要根據需求重新派生一個實作類別來擴充就可以了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。

 

IOS設計模式六大法則