facade（外觀）模式：是為子系統中的一組介面提供乙個一致的介面。該模式理解起來還是比較容易的，舉個例子：
class
eye};
class
mouse
};class
nose};
我們有眼睛，嘴，鼻子這樣的類。一般來說臉的組成是一定的，那我們就可以提供乙個face類，如下：
class
face};
一般情況下，eye，mouse和nose的使用都是這樣的乙個過程。而fa?ade的目的就是為一般情況提供乙個簡化的介面，使用者直接呼叫face就可以了，不需要自己去呼叫eye等類了。
flyweight（享元）模式：應用共享技術有效地支援細粒度的物件。這個模式，我自己想不到太好的例子，簡單的把《設計模式》上的例子在這兒再序述一下。假如我們做乙個文字編輯器，準備把每個字元做為乙個物件，那麼我們可能有這樣乙個類：
class
character};
可以看到每個字元都包括字型，顏色等資訊。這樣的話，每個字元都會占用比較大的空間，而我們知道來般來說一篇文章中有很多重複的字元（尤其是英文，總共就那麼26個字母），為每個字元都提供乙個物件，是種浪費。這時候就可以利用flyweight模式，可以提供乙個鍊錶，把出現了的字元組合放到鍊錶中。這樣使用字元的時候，只要有它在鍊錶中的位置就可以了（可能是個整數，也可能是乙個指標，總之比character會小很多）。具體如何去用，大家可以參考《設計模式》一書。
proxy（**）模式：該模式其實很簡單，目的就是幫助遠端物件或者占用空間比較大的物件提供乙個**介面，這樣只有在真正需要被**類的時候，才把它載入記憶體。還是《設計模式》上的例子，簡單看一下：
class
imageproxy
_image.draw(); }};
不多寫了，**類會擁有乙個它**的類的物件，如draw()中，只有在真正需要_image的時候才把它載入記憶體。
chain of responsibility（責任鏈）模式：該模式的目的是使多個物件有機會處理請求，如果乙個物件不對請求作出響應，則沿著鍊錶傳遞請求，直到找到可以處理該請求的物件為止。mfc中的訊息處理機制就是如此實現的，有興趣的可以找來看看。
interpreter（直譯器）模式，其實就是composite模式，《設計模式》書上有一段描述說interpreter不是composite模式，但我沒搞明白究竟在說什麼（不知道是不是翻譯的變了味）。反正它和composite模式形式上沒有太多區別。
mediator（中介者）模式，感覺不容易簡單講明白，還是自己看書吧。事實上也不難理解。
memento（備忘錄）模式，這個模式沒什麼好講的，就是在操作過程中，乙個物件的狀態可能改變，為了支援返回操作，可能需要把該物件的狀態記錄下來，這樣的話就需要提供乙個memento類了。
template method（摸版方法），該模式主要用在框架中，如mfc中。方法的就是在基類中定義乙個操作演算法的骨架，而將一些函式延遲到子類中才實現。例子還是看書吧，其實實現方法和工廠方法類似。
設計模式之十一（建造者模式）
前言 建造者模式，將乙個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。結構圖 builder是為建立乙個product物件的各個部件指定的抽象介面。concretebuilder是具體的建造者，實現builder介面，構造和裝配各個部件。可以有多個不同的具體的建造者。produ...
設計模式十一之享元模式
2.模式的結構與實現 3.模式在開源軟體中的應用 在物件導向程式設計過程中，有時會面臨要建立大量相同或相似物件例項的問題。建立那麼多的物件將會耗費很多的系統資源，它是系統效能提高的乙個瓶頸。這些物件有很多相似的地方，如果能把它們相同的部分提取出來共享，則能節省大量的系統資源，這就是享元模式的產生背景...
設計模式之十一 Facade 外觀
問題 在實際應用中，我們可能封裝了很多類，但是這些類只是乙個業務的各個步驟，如果讓客戶端乙個乙個去呼叫這些介面，是非常繁瑣的一件事。我們應該簡化客戶端的操作。解決方案 我們可以設計乙個類 這個類組合了所有的必須的類，然後在乙個方法中呼叫所有的實現，並把這個類提供給客戶端，這就是facade 模式 外...