前三篇，嘎嘎。

設(shè)計模式小結(jié)（三）
設(shè)計模式小結(jié)（二）
設(shè)計模式小結(jié)（一）

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

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

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

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

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

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


Template Method
Template Method是一個有點兒違背面向?qū)ο笤瓌t的模式。它雖然簡化了代碼結(jié)構(gòu)，但是由于將一致性的維護分散在了子類和父類兩個不同的部分，提高了代碼的閱讀難度。同時這也是一個實現(xiàn)繼承而不是接口繼承的例子。面向?qū)ο笤瓌t這個東西究竟只是原則，實際應(yīng)用的時候，也是會有一定程度的變通。當(dāng)然這變通也要付出代價的。雖然我不喜歡Template Method，但是仍然會經(jīng)常的使用它，因為我遵循Kent Beck大牛的懶惰是程序員的美德這一教導(dǎo)，同時也是因為執(zhí)迷于Occam剃刀的美感。

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

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

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