http://bbs.51aspx.com/showtopic-43429.html
建立型模式
工廠方法（Factory Method）
在工廠方法模式中，工廠方法用來建立客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被例項化這一細節。工廠方法模式的核心是一個抽象工廠類，各種具體工廠類通過抽象工廠類將工廠方法繼承下來。如此使得客戶可以只關心抽象產品和抽象工廠，完全不用理會返回的是哪一種具體產品，也不用關係它是如何被具體工廠建立的。
抽象工廠模式（Abstract Factory）
抽象工廠模式的主要優點是隔離了具體類的生成，使得客戶不需要知道什麼被建立了。猶豫這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現了抽象工廠中定義的那些公共介面，因此只需改變具體工廠的例項，就可以在某種程度上改變這個 軟體的 系統的行為。另外，應用抽象工廠模式符合GRASP純虛構的模式，可以實現高內聚低耦合的 設計目的，因此抽象工廠模式得到了廣泛應用。
建造者模式（Builder Pattern）
建造者模式將一個複雜物件的生成責任作了很好的分配。它把構造過程放在指揮者的方法中，把裝配過程放到具體建造者類中。建造者模式的產品之間都有共通點，但有時候，產品之間的差異性很大，這就需要藉助工廠方法模式或抽象工廠模式。另外，如果產品的內部變化複雜，Builder的每一個子類都需要對應到不同的產品去做構建的動作、方法，這就需要定義很多個具體建造類來實現這種變化。
單件模式（Single Pattern）
Singleton單例模式為一個物件導向的應用程式提供了物件唯一的訪問點，不管它實現何種功能，此種模式都為設計及 開發團隊提供了共享的概念。然而，Singleton物件類派生子類就有很大的困難，只有在父類沒有被例項化時才可以實現。值得注意的是，有些物件不可以做成Singleton，比如.net的 資料庫連結物件(Connection)，整個應用程式同享一個Connection物件會出現連線池溢位錯誤。另外，.net提供了自動廢物回收的技術，因此，如果例項化的物件長時間不被利用，系統會認為它是廢物，自動消滅它並回收它的資源，下次利用時又會重新例項化，這種情況下應注意其狀態的丟失。
原型模式（Protype Pattern）
原型模式得到了廣泛的應用，特別是在建立物件成本較大的情況下(初始化需佔用較長時間，佔用太多CPU資源或網路資源。比如通過Webservice或DCOM建立物件，或者建立物件要裝載大檔案)，系統如果需要重複利用，新的物件可以通過原型模式對已有物件的屬性進行復制並稍作修改來取得。另外，如果系統要儲存物件的狀態而物件的狀態變化很小，或者物件本身佔記憶體不大的時候，也可以用原型模式配合備忘錄模式來應用。相反地，如果物件的狀態變化很大，或者物件佔用記憶體很大，那麼採用狀態模式會比原型模式更好。原型模式的缺點是在實現深層複製時需要編寫複雜的程式碼。
結構型模式
介面卡模式（Adapter Pattern）
介面卡模式可以將一個類的介面和另一個類的介面匹配起來，使用的前提是你不能或不想修改原來的介面卡母介面(adaptee)。例如，你向第三方購買了一些類、控制元件，但是沒有源程式，這時，使用介面卡模式，你可以統一物件訪問介面。但客戶呼叫可能需要變動。
橋接模式（Bridge Pattern）
橋接模式可以從介面中分離實現功能，使得設計更具擴充套件性，這樣，客戶呼叫方法時根本不需要知道實現的細節。
橋接模式減少了子類，假設程式要在2個作業系統中處理6種影像格式，純粹的繼承就需要(2*6)12個子類，而應用橋接模式，只需要(2+6)8個子類。它使得程式碼更清潔，生成的執行程式檔案更小。
橋接模式的缺陷是抽象類與實現類的雙向連線使得執行速度減慢。
組合模式（Composite Pattern）
組合模式可以清楚地定義分層次的複雜物件，表示物件的全部或部分層次，使得增加新部件也更容易，因為它讓客戶忽略了層次的不同性，而它的結構又是動態的，提供了物件管理的靈活介面。組合模式對於樹結構的控制有著神奇的功效，例如在人力資源系統的組織架構及 ERP系統的BOM設計中，組合模式得到重點應用。
組合模式的缺陷是使得設計變得更加抽象。物件的商業規則如果很複雜，則實現組合模式具有很大挑戰性，並且，不是所有的方法都與葉部件子類有關聯。
裝飾模式（Decorator Pattern）
裝飾模式提供了比靜態繼承更好的柔韌性，它允許開發一系列的功能類用來代替增加物件的行為，這既不會汙染原來物件的 原始碼，還能使程式碼更容易編寫，使類更具擴充套件性，因為變化都是由新的裝飾類來完成。還可以建立連線的裝飾物件關係鏈。
需要注意的是，裝飾鏈不宜過長。裝飾鏈太長會使系統花費較長時間用於初始化物件，同時資訊在鏈中的傳遞也會浪費太多的時間。這個情況好比物品包裝，包了一層又一層，大包套小包。另外，如果原來的物件介面發生變化，它所以的裝飾類都要修改以匹配它的變化。派生子類會影響物件的內部，而一個Decorator只會影響物件的外表。
工廠方法（Factory Method）
在工廠方法模式中，工廠方法用來建立客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被例項化這一細節。工廠方法模式的核心是一個抽象工廠類，各種具體工廠類通過抽象工廠類將工廠方法繼承下來。如此使得客戶可以只關心抽象產品和抽象工廠，完全不用理會返回的是哪一種具體產品，也不用關係它是如何被具體工廠建立的。
抽象工廠模式（Abstract Factory）
抽象工廠模式的主要優點是隔離了具體類的生成，使得客戶不需要知道什麼被建立了。猶豫這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現了抽象工廠中定義的那些公共介面，因此只需改變具體工廠的例項，就可以在某種程度上改變這個 軟體的 系統的行為。另外，應用抽象工廠模式符合GRASP純虛構的模式，可以實現高內聚低耦合的 設計目的，因此抽象工廠模式得到了廣泛應用。
建造者模式（Builder Pattern）
建造者模式將一個複雜物件的生成責任作了很好的分配。它把構造過程放在指揮者的方法中，把裝配過程放到具體建造者類中。建造者模式的產品之間都有共通點，但有時候，產品之間的差異性很大，這就需要藉助工廠方法模式或抽象工廠模式。另外，如果產品的內部變化複雜，Builder的每一個子類都需要對應到不同的產品去做構建的動作、方法，這就需要定義很多個具體建造類來實現這種變化。
單件模式（Single Pattern）
Singleton單例模式為一個物件導向的應用程式提供了物件唯一的訪問點，不管它實現何種功能，此種模式都為設計及 開發團隊提供了共享的概念。然而，Singleton物件類派生子類就有很大的困難，只有在父類沒有被例項化時才可以實現。值得注意的是，有些物件不可以做成Singleton，比如.net的 資料庫連結物件(Connection)，整個應用程式同享一個Connection物件會出現連線池溢位錯誤。另外，.net提供了自動廢物回收的技術，因此，如果例項化的物件長時間不被利用，系統會認為它是廢物，自動消滅它並回收它的資源，下次利用時又會重新例項化，這種情況下應注意其狀態的丟失。
原型模式（Protype Pattern）
原型模式得到了廣泛的應用，特別是在建立物件成本較大的情況下(初始化需佔用較長時間，佔用太多CPU資源或網路資源。比如通過Webservice或DCOM建立物件，或者建立物件要裝載大檔案)，系統如果需要重複利用，新的物件可以通過原型模式對已有物件的屬性進行復制並稍作修改來取得。另外，如果系統要儲存物件的狀態而物件的狀態變化很小，或者物件本身佔記憶體不大的時候，也可以用原型模式配合備忘錄模式來應用。相反地，如果物件的狀態變化很大，或者物件佔用記憶體很大，那麼採用狀態模式會比原型模式更好。原型模式的缺點是在實現深層複製時需要編寫複雜的程式碼。
結構型模式
介面卡模式（Adapter Pattern）
介面卡模式可以將一個類的介面和另一個類的介面匹配起來，使用的前提是你不能或不想修改原來的介面卡母介面(adaptee)。例如，你向第三方購買了一些類、控制元件，但是沒有源程式，這時，使用介面卡模式，你可以統一物件訪問介面。但客戶呼叫可能需要變動。
橋接模式（Bridge Pattern）
橋接模式可以從介面中分離實現功能，使得設計更具擴充套件性，這樣，客戶呼叫方法時根本不需要知道實現的細節。
橋接模式減少了子類，假設程式要在2個作業系統中處理6種影像格式，純粹的繼承就需要(2*6)12個子類，而應用橋接模式，只需要(2+6)8個子類。它使得程式碼更清潔，生成的執行程式檔案更小。
橋接模式的缺陷是抽象類與實現類的雙向連線使得執行速度減慢。
組合模式（Composite Pattern）
組合模式可以清楚地定義分層次的複雜物件，表示物件的全部或部分層次，使得增加新部件也更容易，因為它讓客戶忽略了層次的不同性，而它的結構又是動態的，提供了物件管理的靈活介面。組合模式對於樹結構的控制有著神奇的功效，例如在人力資源系統的組織架構及 ERP系統的BOM設計中，組合模式得到重點應用。
組合模式的缺陷是使得設計變得更加抽象。物件的商業規則如果很複雜，則實現組合模式具有很大挑戰性，並且，不是所有的方法都與葉部件子類有關聯。
裝飾模式（Decorator Pattern）
裝飾模式提供了比靜態繼承更好的柔韌性，它允許開發一系列的功能類用來代替增加物件的行為，這既不會汙染原來物件的 原始碼，還能使程式碼更容易編寫，使類更具擴充套件性，因為變化都是由新的裝飾類來完成。還可以建立連線的裝飾物件關係鏈。
需要注意的是，裝飾鏈不宜過長。裝飾鏈太長會使系統花費較長時間用於初始化物件，同時資訊在鏈中的傳遞也會浪費太多的時間。這個情況好比物品包裝，包了一層又一層，大包套小包。另外，如果原來的物件介面發生變化，它所以的裝飾類都要修改以匹配它的變化。派生子類會影響物件的內部，而一個Decorator只會影響物件的外表。
外觀模式（Façade Pattern）
外觀模式提供了一個簡單且公用的介面去處理複雜的子系統，並且沒有減少子系統的功能。它遮蔽了子系統的複雜性，避免了客戶與子系統直接連結，它也減少了子系統與子系統間的連線，每個子系統都有它的Facade模式，每個子系統採用Facade模式去訪問其他子系統。外觀模式的劣勢就是限制了客戶的自由，減少了可變性。
享元模式（Flyweight Pattern）
Flyweight模式需要你認真考慮如何能細化物件，以減少處理的物件數量，從而減少存留物件在記憶體或其他儲存裝置中的佔用量。然而，此模式需要維護大量物件的外部狀態，如果外部狀態的資料量大，傳遞、查詢、計算這些惡資料會變得非常複雜。當外部和內部的狀態很難分清時，不宜採用flyweight模式。
代理模式（Proxy Pattern）
當物件在遠端機器上，要通過網路來生成時，速度可能會慢，此時應用Remote Proxy模式，可以掩蔽物件由網路生成的過程，系統的速度會加快；對於大圖片的載入，Virtual Proxy模式可以讓載入在後臺進行，前臺用的Proxy物件使得整體執行速度得到優化；Protect Proxy可以驗證對真實物件的引用許可權。
代理模式的缺陷是請求的處理速度會變慢，並且實現Proxy模式需要額外的工作。
行為型模式
職責鏈模式（Chain of Responsibility）
責任鏈模式可以減少物件的連線，為物件責任分配增加了很大的靈活性。該模式允許把一組類作為一個類來使用，並且在類的組合中，一個類的事件可以傳送到另一個類並由其處理。
責任鏈模式通常應用與圖形使用者介面中，窗體的部件可能會包含其他幾個小部件，就如同Windows窗體應用程式中，控制元件中又可以放置其他控制元件，控制元件邊界會決定是否處理事件，或者將事件傳遞給父控制元件來處理。
另外，責任鏈還會以樹狀出現，這樣，一個事件可以傳給多個類，或者，多個類的資訊可以提交到一個類。樹狀責任鏈能夠提供更靈活的技巧，但缺點是資訊在樹中容易迷失。
命令模式（Command Pattern）
命令模式分離了接受請求的物件與實現處理請求工作的物件，這樣，已經存在的類可以保持不變，使得增加新類的工作更簡單。例如，很多軟體的巨集命令就提高了系統的自動化程度。
命令模式還可以分離使用者介面和業務物件，降低系統的耦合度。
但是，命令模式最主要的缺陷就是，類的數量增加了，系統變得更復雜，程式的除錯工作也相應變得困難。
直譯器模式（Interpreter Pattern）
直譯器模式的作用很強大，它使得改變和擴充套件文法變得容易，實現文法也變得簡單明瞭，很多編譯器，包括文字編輯器、網頁瀏覽器及VRML都應用直譯器模式。
直譯器模式的缺陷就是，因為文句會分析成樹結構，直譯器需要遞迴訪問它，所以效率會受影響。這種情況開發人員會有所體會，編譯整個工程原始碼耗費時間都比較長。
模版方法模式（Template Method）
模版方法模式在一個類中形式化地定義演算法，而由它的子類實現細節的處理。模版方法模式的優勢是，在子類定義處理演算法時不會改變演算法的結構。
模版方法的特點在於，每個不同的實現都需要定義一個子類，這也複合高內聚的責任分配模式，不能說成是它的缺點。
迭代器模式（Iterator Pattern）
迭代器模式支援在聚集中移動遊標，使得訪問聚合中的元素變得簡單，簡化了聚集的介面，封裝了聚合的物件。
迭代器模式還可以應用於對樹結構的訪問，程式不需要從頭逐行程式碼查詢相應位置，可控制到從子集開始查詢，對於加快程式的執行速度有很重要的作用。
迭代器模式的缺點是聚合密切相關，增加了耦合。但將這種耦合定義在抽象基類，可解決這個問題。
觀察者模式（Oberver Pattern）
觀察者模式抽象了被觀察物件與觀察者物件的連線，提供了廣播式的物件間通訊，並且容易增加新的觀察者物件。觀察者模式的缺陷是物件間的關係難以理解，在某種情況下會表現低效能。
中介者模式（Mediator Pattern）
中介者模式分離了兩個同事類，簡化了物件協議，中央控制物件互動，從而使個體物件變得更容易且更簡單，因為它不需要傳遞資料給其他個體物件，僅僅傳給中介者就可以了。個體物件不需要具有處理內部交流的邏輯，所以更加突出它的物件導向特性。
備忘錄模式（Memento Pattern）
Memento模式儲存了封裝的邊界，一個Memento物件是另一種原發器物件的表示，不會被其他程式碼改動。這種模式簡化了原發器物件，Memento只儲存原發器的狀態。採用堆疊備忘物件，可以實現多次取消操作。
狀態模式（State Pattern）
狀態模式在物件內儲存特定的狀態並且就不同的狀態履行不同的行為，它使狀態的變化顯得清晰明瞭，也很容易建立物件的新狀態。
狀態模式在工作流或遊戲等各種系統中大量使用，例如在政府 OA系統中，一個批文的狀態有多種：未辦、正在處理、正在批示、正在稽核和已經完成等各種狀態。在網路遊戲中，一個遊戲活動存在開始、開玩、正在玩、輸贏等各種狀態。使用狀態模式就可以實現遊戲狀態的總控，而遊戲狀態決定了遊戲的各個方面。
策略模式（Strategy Pattern）
策略模式提供了替代派生的子類，並定義類的每個行為，剔除了程式碼中條件的判斷語句，使得擴充套件和結合新的行為變得更容易，根本不需要變動應用程式。策略模式可以避免使用多重條件轉移語句，系統變得更新靈活。應用策略模式會產生很多子類，這符合高內聚的責任分配模式。
訪問者模式（Visitor Pattern）
Visitor(訪問者)模式使得增加新的操作變得容易，它可以收集有關聯的方法，而分離沒有關聯的方法，特別適用於分離因為不同原因而變化的事物，如“在男人中分離出男孩”。但Visitor模式常常要打破物件的封裝性，visitor與element需要達成某些共識。