設計模式的實現並不難，對著例子來，很快就能敲出來。但是，在什麼情況下用什麼設計模式，這是個問題，最近總結了一下：
設計模式
用法單例
保證類的例項只有乙個
簡單工廠
根據引數建立對應具體子類
策略演算法、規則的封裝、傳入具體呼叫，呼叫具體演算法
裝飾者動態對乙個物件進行增屬性、呼叫方法等操作，鏈式操作，隨意組合。梳頭、畫眉、只梳頭不畫眉、只畫眉不梳頭
工廠方法
建立類，乙個實現類要有乙個工廠類。總是通過對應的工廠類建立實現類，判斷在客戶端進行。工廠類太多。
**物件中儲存能執行另一種操作的物件，通過這個儲存的物件去操作。
原型用轉殖(clone)，代替new物件。轉殖的方式能夠保留一些同樣的資訊。
模板方法
提煉出相同的公共**，封裝為乙個方法模板。
外觀通過改造內部實現，讓外部看起來呼叫的方式很簡單(如，實際需要呼叫3個方法，但增加乙個方法來呼叫這3個方法，讓外部只呼叫乙個方法即可)。
建造者將乙個複製物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。
觀察者觀察者類裡面放了乙個集合，包含了多個被通知類，被通知類實現乙個抽象方法，有乙個方法接受通知。
抽象工廠
增加乙個介面，讓外部依賴介面而不是具體類
狀態多個大致相同的類，只是狀態不同，隨著不停的呼叫，乙個狀態會轉為另乙個狀態(乙個類轉為另乙個類)
介面卡將乙個類的介面轉換成客戶希望的另外乙個介面。 可以理解為，僅僅改為乙個方法名，在方法內部呼叫真正的方法(名字不同)。
備忘錄增加乙個類用於儲存狀態，乙個類負責備份和恢復狀態
組合部分-整體關係，解決無限遞迴問題。
迭代器分離了集合物件的遍歷行為，抽象出乙個迭代器類來負責。解決遍歷問題
橋接將繼承關係分離出來改為聚合關係
命令對請求的封裝，請求-》真正執行(佇列)
職責鏈類似於asp.net管道，一條鏈操作，每個類都有處理的機會，沒許可權就往上級拋，直到有許可權的類能夠處理
中介者通過乙個中介類來處理兩個類之間的資訊交換
享元物件的大多數狀態為外部狀態，如果刪除物件的外部狀態，那麼可以用相對較少的共享物件取代很多組物件。
訪問者它把資料結構和作用於結構上的操作之間的耦合解脫開（用類封裝變化的資料）
直譯器用類去封裝一條規則
設計模式總結
http www.chenjiliang.com article view.aspx?articleid 6708 比較 設計模式 常用程度 適用層次 引入時機 結構複雜度 abstract factory 比較常用 應用級設計時 比較複雜 builder 一般 級 編碼時一般 factory me...
設計模式總結
模式相關的描述 裝飾者 包裝乙個物件，以提供新的行為 狀態 封閉了基於狀態的行為，並使用委託在行為之間切換 迭代器 在物件的集合之間遊走，而不暴露集合的實現 外觀 簡化一群類的介面 策略 封閉可以互換的行為，並使用委託來決定要使用哪乙個 包裝物件，以控制對此物件的訪問 工廠方法 由子類來決定要建立的...
設計模式總結
這類模式的特質是管理物件的建立過程。通常設計總是以使用工廠方法開始，當設計者發現需要更大的靈活性時，設計會向其它建立型模式演化。工廠方法模式 單例模式 抽象工廠方法模式 建造者模式 原型模式 簡單工廠模式 這類模式從程式的結構上解決模組之間的耦合問題。介面卡模式 裝飾模式 橋接模式 組合模式 享元模...