本篇是四部曲的第三篇，第一篇請點這里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，歡迎一起交流，一起進步！??
