iOS設計模式四部曲(三):行為型模式 內附Demo

本篇是四部曲的第三篇，第一篇請點這裡iOS設計模式四部曲(一):建立型模式,第二篇請點選這裡iOS設計模式四部曲(二):結構型模式。由於個人能力有限，文中難免有一些遺漏或者錯誤，請各位看官不吝賜教！謝謝！本文所有Demo可以在我的Git上獲取，請點選這裡

上圖是整個設計模式的目錄，這篇文章是其中的第三部分：行為型模式。行為型模式包括：責任鏈模式（Chain of Responsibility），命令模式（Command），中介者模式（Mediator），觀察者模式（Observer），備忘錄模式（Memento），策略模式（Strategy），訪問者模式（Visitor），模板方法模式（TemplateMethod），狀態模式（State），迭代器模式（Iterator），直譯器模式（Interpreter）。下面我們就開始吧~

責任鏈模式（Chain of Responsibility）：

1.定義: 責任鏈模式（Chain of Responsibility Pattern）為請求建立了一個接收者物件的鏈。使多個物件都有機會處理請求，從而避免了請求的傳送者和接受者之前的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，知道有物件處理它為止。
2. 使用場景： 有多個物件可以處理同一個請求，具體哪個物件處理該請求由執行時確定。
3. 具體實現： 這裡舉了一個實際中公司請假批假的例子，具體請點選這裡檢視
4.優點： 1.低耦合：將請求和處理分開，請求者可以不用知道是誰處理的。2.新增和修改新的處理類比較容易
5.缺點： 每個請求都是從鏈頭遍歷到鏈尾，如果鏈比較長會產生一定的效能問題，除錯起來也比較麻煩。
6.注意事項: 避免超長鏈的情況出現

---

命令模式（Command）：

1.定義: 命令模式將請求封裝成物件，從而可用不同的請求對客戶進行引數化，對請求排隊或記錄請求日誌，以及支援可撤銷和恢復的操作。
2. 使用場景： 在某些場合，比如要對行為進行"記錄、撤銷/重做、事務"等處理的時候。
3. 具體實現： YTKNetwork就是用的命令模式，推薦大家學習。這裡我舉了一個吃飯點菜的例子，具體請點選這裡檢視
4.優點： 1.類間解耦：呼叫者與接收者之間沒有任何依賴關係。2.擴充套件性良好：新的命令可以很容易新增到系統中去。
5.缺點： 使用命令模式可能會導致系統有過多的具體命令類。

---

中介者模式（Mediator）：

1.定義: 中介者模式就是用一箇中介物件來封裝一系列的物件互動，中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。
2. 使用場景： 多個類相互依賴，形成了網狀結構的時候可以考慮使用中介者模式。
3. 具體實現： 這裡舉了一個聊天室的例子，具體請點選這裡檢視
4.優點： 1.解耦：通過中介者模式，我們可以將複雜關係的網狀結構變成結構簡單的以中介者為核心的星形結構，每個物件不再和它與之關聯的物件直接發生相互作用，而是通過中介者物件來另一個物件發生相互作用。2.降低了類的複雜度，將一對多轉化成了一對一。
5.缺點：中介者模式在某些情況會膨脹得很大，而且邏輯複雜，中介類越多越複雜，越難以維護。
6.注意事項: 類之間的依賴關係是必然存在的，所以不一定有多個依賴關係的時候就考慮使用中介者模式。中介者模式適用於多個物件之間的緊密耦合的情況，緊密耦合的定義標準是：在類圖中出現了蜘蛛網狀結構，這種情況就要考慮使用中介者模式，中介者模式可以把蜘蛛網梳理成星型結構，使原本複雜混亂的關係變得清晰簡單。

---

觀察者模式（Observer）：

1.定義: 定義物件間的一種一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被自動更新。
2. 使用場景： 一個物件的狀態發生改變，所有的依賴物件都將得到通知的時候。
3. 具體實現： Objective-C中的通知以及KVO都是觀察者模式的具體實現。這裡舉了一個找工作訂閱的例子，具體請點選這裡檢視
4.優點： 1.觀察者和被觀察者是抽象耦合的，擴充套件比較方便。2.建立一套觸發機制。
5.缺點： 1.如果一個被觀察者物件有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。 2.如果在觀察者和觀察目標之間有迴圈依賴的話，觀察目標會觸發它們之間進行迴圈呼叫，可能導致系統崩潰。 3.觀察者模式沒有相應的機制讓觀察者知道所觀察的目標物件是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。

---

備忘錄模式（Memento）：

1.定義: 在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就開獎物件恢復到原先儲存的狀態了。
2. 使用場景： 需要存檔的時候，比如說遊戲中的存檔。
3. 具體實現： 打遊戲時的存檔，資料庫的事務管理，SVN以及Git程式碼的版本控制系統等等都可以說成是備忘錄模式的例項。這裡我簡單的舉了一下例子，具體請點選這裡檢視
4.優點： 1.給使用者提供了一種可以恢復狀態的機制，可以使使用者能夠比較方便地回到某個歷史的狀態。 2.實現了資訊的封裝，使得使用者不需要關心狀態的儲存細節。
5.缺點： 在一些場景下比較消耗資源。
6.注意事項: 不要在頻繁建立備份的場景中使用備忘錄模式，比如說在for迴圈中。

---

策略模式（Strategy）：

1.定義: 定義一系列的演算法，把它們一個個封裝起來，並且使它們可相互替換。
2. 使用場景： 1.多個類只有在演算法或行為上稍有不同的場景。2.演算法需要自由切換的場景。3.需要遮蔽演算法規則的場景。
3. 具體實現： 具體請點選這裡檢視
4.優點： 1.演算法可以自由切換。 2.避免使用多重條件判斷。 3.擴充套件性良好。
5.缺點：1.策略類會增多。 2.所有策略類都需要對外暴露。
6.注意事項: 如果一個系統的策略多於四個，就需要考慮使用混合模式，解決策略類膨脹的問題。

---

訪問者模式（Visitor）：

1.定義: 訪問者模式封裝了一些作用於某種資料結構中的各元素操作，它可以在不改變資料結構的前提下定義作用於這些元素的新的操作。
2. 使用場景： 需要對一個物件結構中的物件進行很多不同的並且不相關的操作，而需要避免讓這些操作"汙染"這些物件的類，使用訪問者模式將這些封裝到類中。
3. 具體實現： 這裡舉了一個悲觀的人和樂觀的人對待不同事物的反應的例項，具體請點選這裡檢視，如果想增加Action就比較方便，但是如果想增加一個既悲觀又樂觀的人就有一點麻煩了。
4.優點： 1.符合單一職責原則。 2.優秀的擴充套件性。 3.靈活性高
5.缺點：1.具體元素對訪問者公佈細節，違反了迪米特原則。 2.具體元素變更比較困難。 3.違反了依賴倒置原則，依賴了具體類，沒有依賴抽象。

---

模板方法模式（TemplateMethod）：

1.定義: 定義一個操作中的演算法的框架，而降一些步驟延遲到子類中。使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。
2. 使用場景： 1.多個子類有公有的方法，並且邏輯基本相同時。2.有重要、複雜的演算法的時候，可以把核心演算法設計為模板方法，周邊的相關細節功能則由各個子類實現。
3. 具體實現： 這裡簡單舉了一個Android 和iOS專案的從code到釋出的簡易過程Demo，具體請點選這裡檢視
4.優點： 1.封裝不變部分，擴充套件可變部分。 2.提取公共程式碼，便於維護。 3.行為由父類控制，子類實現。
5.缺點： 每一個不同的實現都需要一個子類來實現，導致類的個數增加，使得系統更加龐大。

---

狀態模式（State）：

1.定義: 當一個物件內在狀態改變時允許其改變行為，這個物件看起來像改變了其類。
2. 使用場景： 1.行為隨狀態改變而改變的場景。2.條件、分支判斷語句的替代者。
3. 具體實現： 這裡舉了一個不太恰當的例子，假如一支筆有3種狀態可以切換，可以寫鋼筆字，圓珠筆字，毛筆字，具體請點選這裡檢視。再舉一個實際中典型的例子就是酒店管理房間的時候，房間應該會有三種狀態：空閒，已預訂，已入住，同理。
4.優點： 1.結構清晰，避免了過多的選擇判斷語句。2.封裝性比較好。
5.缺點： 子類會比較多，增加了複雜度。

---

迭代器模式（Iterator）：

1.定義: 迭代器模式提供一種方法訪問一個容器物件中各個元素，而又不需暴露該物件的內部細節。
2. 使用場景： 一個聚合物件有遍歷的需求
3. 具體實現： 在 Cocoa Touch 中的 NSEnumerator類 就實現了迭代器模式。還有基於塊的列舉也是迭代器模式的實現等等
4.優點： 1.它支援以不同的方式遍歷一個聚合物件。2.增加新的collection類和迭代器類都很方便。
5.缺點： 迭代器和collection類是對應的，增加新的collection類就會增加新的迭代器，類的個數成對增加，可能會增加系統複雜度。

---

直譯器模式（Interpreter）：

1.定義: 給定一門語言，定義它的文法的一種表示，並定義一個直譯器，該直譯器使用該表示來解釋語言中的句子。
2. 使用場景： 直譯器模式在實際專案中用到的比較少，正規表示式就是用的直譯器模式。
3. 具體實現： 正規表示式。
4.優點： 容易改變和擴充套件問法。
5.缺點： 效率是嚴重的問題。

---

擴充套件閱讀：
iOS 中的 21 種設計模式
https://github.com/kamranahmedse/design-patterns-for-humans

---

EOF:這篇文章通過Demo梳理了設計模式中的行為型模式，由於個人能力有限，難免有一些遺漏或者錯誤，還請各位看官不吝賜教！ 本文已同步到個人部落格，歡迎關注，歡迎點贊，歡迎star，歡迎一起交流，一起進步！?