最近由于忙著準備實習單位的面試，加上導師的任務，所以更新的有點慢，希望大家能諒解。

下面繼續。

Decorator
描述：
動態、透明的為對象添加職責。
適用性/作用：
該模式有兩個主要參與者，Decoratee和Decorator。前者為原有的對象，而后者則是在前者的基礎上添加了新的功能。在GOF的描述中，Decorator和Decoratee使用了相同的接口。同時大部分的相關材料都側重于這一模式“添加職責”的功能。但是有一點個人認為，在該模式的使用中還有兩點值得考慮。
首先，Decorator和Decoratee不僅在繼承體系中屬于同一層，在整個系統的功能體系中也應當是平級的。Decoratee自身也需要有相當的可能性被獨立的使用到，否則在兩個對象之間建立Decorator-Decoratee的關系就不那么必要，也許將Decoratee在功能體系中下移是個更好的選擇，因為它會避開“相同接口”這樣一個限制；
其次，Decorator之間的功能劃分最好是正交的。一旦Decorator之間出現了不一致性，那么Decorator的裝飾次序將會影響到實際的結果，或者對某個Decorator而言Decoratee存在著限制。而這些運行時才有的特性很難在靜態設計中體現出來，會造成對系統功能的理解造成障礙。

Facade
描述：
為子系統中的一組接口提供一個統一的界面
適用性/作用：
由于子系統間的類聯系比較緊密，他們通常會一一種固定的協作方式完成某項任務。當客戶代碼多以這種粗粒度的方式與子系統打交道時，Facade模式便有必要起來。
Facade模式可以用來解決以下兩個問題。
第一，如果某種粗粒度任務都是由一系列的細粒度組件以一定的語義關系耦合起來。而客戶代碼只關心這種粗粒度的任務，但不關心這個任務究竟怎樣由子系統的組件合作完成的。那么這是，可以使用Facade模式將細粒度之間的語義耦合封裝起來，并且這種封裝可以防止子系統組件間合作的改變對客戶代碼造成影響。
第二，也就是GOF所描述的，簡化客戶使用子系統的復雜度。
Facade本身的設計在實踐過程中會遇到以下幾種情況。
第一種情況下，Facade本身具有很高的內聚，同時它完全封裝了子系統（說明子系統內聚度高），客戶代碼不需要知道子系統的細節便可以用Facade完成全部的工作。這一點是最理想的情況。
更多的可能是，Facade不能包辦一切，程序既要與子系統打交道，也要與Facade打交道。這種情況下，如果Facade使用不當，便會破壞系統的層次結構。
個人的經驗是，
如果一些子任務可以由Facade封裝而完全不需要與子系統打交道，便對子系統的部分粗粒度任務使用Facade模式，保持局部的內聚性和抽象能力；
如果一個功能，客戶通常都直接調用Facade，但是在少數情況下不可避免的要與細粒度組件打交道，那么通常我會將Facade旁置為一些Help Function，讓它們與子系統組件處于差不多同樣的地位，并以文檔顯示地注明其實現原理。
當然，能通過修改子系統的設計避免這種情況的出現是最完美的結局了。

Flyweight
適用性/作用：
呃，關于這個我想GOF已經描述的非常好了，我也就不說廢話了。注意Flyweight在其它模式中的應用就行了。我經常就會在該用它的時候忘了用了。Flyweights通常由pool手法實現。

Proxy
適用性/作用：
Proxy的目的很明確，在維持原有接口和功能設計情況下，解除原始對象的限制。這最后的一句話是我的理解。通常一個對象實現一個功能直接實現就可以了；但是在一些應用中，會有一些與功能無關的限制和要求，例如對象可能是遠程的，或者有內存方面的限制等等。為了解除這些限制，需要一些額外的手法來達到這樣的目的。但是它們所附加的內容在功能設計時并沒有描述。也就是說，這些不是客戶需要關心的，它們應該被抽象掉。Proxy就是為了隱藏這些與代碼的核心功能無關的實現，讓客戶端認為它是個沒有限制的對象。

對象型模式講完了，下面的行為型模式我大概分兩次講，歡迎大家的板磚。