前三篇，嘎嘎。

設計模式小結（三）
設計模式小結（二）
設計模式小結（一）

Mediator/Observer：
描述：將復雜的組件間交互集中到Mediator中/將復雜組件的交互用Observer - Subject相分離。
動機：軟件的復雜之處就在于處理各個組分之間的聯系。處理聯系一般有兩種方式，第一種是將相對獨立的點進行有效的劃分和隔離，減少軟件之間的聯系總數，降低復雜度。但是如果這些點之間關系太過復雜，那么劃分是無法解決根本復雜度的，這時候，一種可選的方案是干脆將所有的聯系封裝到一點，讓那些本該獨立的部分不至于被這些藕斷絲連拖累到一起。
對于大多數模式而言，顯然前者是比較理想的選擇。而Mediator幾乎就是23.5個設計模式里面的特例，它的指導思想是將聯系及其在軟件生命周期中的變化集中到一處以方便管理。

用法：用于維護多個狀態的一致性。Mediator和Observer通常可換用。

Mediator更加適用的情況：當操作本身出現強關聯性而不是在數據上出現關聯性，比方說一些消息的連鎖觸發。當然也可以把這一觸發過程建模成事件后看做是狀態的更改而啟用Observer模式。
如果需要協調的類是不可更改的，且高度復雜或難于擴充，如第三方GUI控件，那么通常也會使用Mediator而不是Observer。
想用Observer？當然也可以，如果你愿意使用Adapter，Decorator或者Proxy等模式將目標控件封裝起來，自然也是可以做到的。
更新操作需要高度集中或者需要高度優化時，需要選擇Mediator，這也是緊耦合的擅長之處。

Observer的優勢在于可以輕松的用單向連接或輪詢的方式完成表現層到模型層的交互，因此對于Web一類有特殊限制的應用，Observer要更加適用一些。

Memento：
對于多數系統而言，這一設計幾乎是一定可以見到的。Memento的變種頗多，比如序列化/反序列化，持久化/反持久化，實際上都是完成同樣的工作。
應用：
Memento自身是需要進行再分層并復用的。
通常的Memento分為上下兩層，下層與存儲設備接駁，負責實際的存儲工作。多數語言中的存儲流均可以作為這一層中。在這一層需要為存儲的物理介質提供一定程度的抽象，這樣我們可以不用關心數據流究竟是被存儲到內存中還是數據庫或者網絡服務器上。上層則提供了數據對象的語義，這樣可以為客戶對象提供一個友善的接口，同時這一抽象可以用于滿足其他的需求，如緩存和代理。
Memento有兩種典型的存儲方式，一種是為一類對象提供固定的存儲模式，這種設計可以最小化數據流量，因而可以獲得良好的性能，缺陷在于與對象耦合過于緊密，在面臨對象修改的時候靈活性有著很大的不足，另一種設計是基于查詢表的理念。這種方法靈活性較高，可以使同樣的數據以多個角度展現，缺點在于會遇到類型轉換的問題，存儲效率上較差。代碼的自描述性弱，需要有文檔進行約定。
在實際運用中，Memento模式面臨的一大問題在于對內嵌引用的存儲問題。
如果可以保證存儲與讀取時被保存對象持有的引用不發生任何可見的變化，那么可以直接保存引用本身（例如C++中的指針地址）。
如果被存儲的對象所持有的內嵌引用可以用值進行替換（也就是不共享），那么可以選擇將引用也嵌入式的序列化出來。如果需要將被共享的嵌入對象序列化，那么則需要顯式的將內嵌的每一個獨立的引用標識成一個唯一的句柄。在序列化時，依次的對象進行序列化，并對序列化的對象用句柄標識。在序列化對象時如果遇到了內嵌的引用，則用它的句柄填充到引用的位置上。在反序列化時，第一步是先將各個句柄反序列化成對象，填充上所有的值域，并重建句柄表，再利用句柄表將各個對象中的句柄用實際引用進行替換。
這一方法的典型運用包括運行狀態的snapshot（例如游戲的讀存盤）。
對于固定初始產生固定序列的系統，如偽隨機，則可以保存它的初始值，并使用過程化的方法產生序列以恢復現場。但是這里需要注意，多線程的系統會加大對象恢復的難度，必須要仔細的考慮，例如僅在線程Join的地方，或線程固定的懸掛點上進行序列化工作。
此外，由于Memento經常保存并恢復完整對象，因此可以將Memento與Deepcopy統一設計實現。
例如運用DeepCopy保存當前對象的狀態，并在恢復狀態時直接用副本替換當前對象，或者將Deepcopy用Memento實現，可以實現對象的遠程復制或狀態同步。

State/Strategy：
State和Strategy的區別很小，他們的差別往往并非來自與程序上的差異而是在觀點上的差異性。
個人認為，和State和Strategy類似的還有Abstract Factory以及Factory Method模式。之所以我將這幾個模式綁定在一起進行討論，本質上是因為他們都將分散在程序各處的分支判斷集中到一處進行管理。
如果將這三個模式進行進一步的抽象，可以總結出它們共同的工作方式：獲得上下文->獲得前置條件并選擇分支->執行分支->設置后置條件->重設上下文。
利用這個工作方式，下面簡單的分析一下這三個模式各自的異同點以及適用面。
AF工作的理想情況是，上下文的獲取、前置條件的設置、分支的選擇放在一起完成。也就是說在一個執行期很靠前的地方就完成了產品線的設置，并且在很長一段運行期中不做更改。分支的執行通常比較Lazy，也很分散。后置條件和上下文設置不存在。
在其他工作條件下，這一模式可能會誘發三個負面問題。第一，是如果產品的創建分散，那么便需要仔細的跟蹤程序的執行流程以確定到底哪一套產品線被構造出來；其次，如果產品系列間的區分不是依靠類型信息而是某個內含的狀態進行區分，會加大對產品線判斷的難度。第三，如果產品系列中對應的產品的構造接口存在這某種語義上的不一致性，或者對應產品本身的接口存在不一致性，都會使得程序的可讀性大大下降。
因此Abstract Factory需要盡可能早的確定產品系列，同時產品系列在確定以后盡可能少做修改。如果產品線確定的很遲，那么最好在使用前再進行創建，并將Abstract Factory的創建活動放在它的產品的管理層上（例如XXXManager或XXXCollection這樣的）。
State和Strategy的情況較為類似，這個工作流程中，各個工序可能很緊湊（例如FSM，有窮狀態機），也有可能很分散。同時由于這一工作流程上下關系緊密，因此各道工序的合并或分離存在多種方案。下面將分析一下State模式。
如果將State的調用方看作State Machine，那么State變化有兩類主要的觸發者，一類來自于State Machine內，一類是來自于State Machine外的客戶代碼。實際上真正需要再State Machine內完成狀態切換操作，基本上都是State之間的相互切換。就是說State本身是狀態切換的觸發者，這里簡寫為State-Triggered Mode（STM）。其他的狀態切換的原因基本上都來自于外部，這里簡寫為Client-Triggered Mode（CTM）。
在設計State時，盡可能避免STM和CTM同時存在。一旦同時存在，由于STM基本上是不可以被放置到State Machine之外的，因此建議將STM和CTM同時封裝在State Machine中，客戶端通過調用State Machine的對應接口實現CTM。這樣可以將State Machine的切換邏輯統一到State中，封裝了可能的變化并提供了更高層的語義。
如果只存在CTM，那么State Machine大可以將State直接以getter/setter的形式提供給客戶代碼訪問，簡化了客戶調用，也能明確客戶的職責。
同時，在存在STM的時候，后置條件和上下文的設置，即狀態切換既可以放在State中，也可以放在State Machine中。在State中直接切換狀態很直接，同時可以在State需要經常修改并改變其后繼狀態的時候很管用，對于很復雜的狀態跳轉規則它也可以Work Well，和State Machine的依賴較小，僅僅需要通知State Machine切換到哪個狀態上就可以了。同時，一旦狀態機中添加或者刪除了狀態，那么也會使得修改擴散到很多地方。
如果在State Machine中進行狀態切換，那么便需要State Machine對State有一定的了解，并且做出正確地決策。如果跳轉規則很復雜，那么State Machine就會變得很麻煩，甚至可能導致State Machine變成一盤大的spaghetti。但是對于如果需要經常添加/刪除State，或者State跳轉規則多但簡單的時候，在State Machine中維護狀態切換會更方便一些。
好吧，我承認這個和Observer/Mediator一樣，兩者都很Perfect，如果你的運氣夠好，你的選擇又正確的話。
如果問題本身就很困難，那就請不要過多的苛責設計，No Silver Bullet嘛。Good Luck，或者重新進行需求分析。


Template Method
Template Method是一個有點兒違背面向對象原則的模式。它雖然簡化了代碼結構，但是由于將一致性的維護分散在了子類和父類兩個不同的部分，提高了代碼的閱讀難度。同時這也是一個實現繼承而不是接口繼承的例子。面向對象原則這個東西究竟只是原則，實際應用的時候，也是會有一定程度的變通。當然這變通也要付出代價的。雖然我不喜歡Template Method，但是仍然會經常的使用它，因為我遵循Kent Beck大牛的懶惰是程序員的美德這一教導，同時也是因為執迷于Occam剃刀的美感。

Visitor
其實我還真不太明白，如果我需要Visitor的時候，還有什么更好的選擇。
并且，如果在遍歷對象的時候無后效性的話（就是對其它對象的操作和當前對象的操作沒什么關系，遍歷結果與順序無關），做起Visitor來，會輕松許多的。

-----------------------------------------------------------------------------------------------------

全文終于完結了。雖然是“泛泛而談”，但是我覺得這個“泛泛”已經比較詳細了。
另外，有些觀點可能GOF上面已經有所闡明，不過我相信大部分應該還是沒有的。
如果還有什么GOF上說的我重復了的話，那我只能贊嘆GOF太博大精深了，以至于我無論看幾遍都會對其中的觀點有所遺漏。
最后祝大家在Design Pattern中游得愉快。