設計模式的精髓在于封裝變化點，對設計模式的理解與掌握，不在于模式中各個類之間的關系理清，更不在于具體的語言，而在于模式面臨的需求場景。要從發現需求變動，準確找到變化點，從如何封裝它的角度去研究，去學習，而不要拘泥于具體的形式。
下面對設計模式進行一個整體的小結：
GOF設計模式劃分為創建型、結構型和行為型。
創建型模式是創建對象而不是直接實例化對象，這會使程序在判斷給定情況下創建哪一個對象時更為靈活。
結構型模式可以將一組對象組合成更大的結構，例如復雜的用戶界面或報表數據。
行為型模式定義系統內對像間的通信，以及復雜程序中的流程控制。
創建型：
抽象工廠：創建一系列“相關或者相互依賴的對象”。
使用場景：
系統中有多個產品族。
客戶不需要知道要對象的創建過程。
客戶使用的對象存在變動的可能，或者根本就不知道使用哪一個具體的對象。
構建器模式：創建一個復雜的對象。
使用場景：
當需要創建的是一個產品，且該產品的內部表現比較復雜。
客戶不需要知道產品的內部細節。
單件模式：為對象生成一個唯一的實例。
使用場景：
系統只要一個實例對象。
客戶調用類的單個實例只允許使用一個公共訪問點。
原型模式：通過對一個已存在的對象克隆來創建另一個相似的對象。
使用場景：
類的實例化是動態的。
類的實例對象只有一個或很少的幾個組合狀態。
結構型：
橋接模式：將抽象部分與實現部分分離，使它們都可以獨立的變化。
使用場景：
避免抽象方法和其實現方法綁定在一起。
抽象接口和它的實現都需要擴展出子類以備使用。
變動實現的方法根本不會影響客戶程序調用部分。
適配器模式：類的接口轉換期望的另外一個接口，從而使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
使用場景：
對象需要利用現在的并且接口不兼容的類。
需要創建可重用的類以作其他接口不一定兼容的類。
需要使用若干個現在的子類但又不想派生這些子類的每一個接口。
裝飾模式：不改變對象結構的情況下給對象添加新的職責。
使用場景：
給對象增加的職責在未來會發生改變。
用子類擴展功能不實際的情況下。
外觀模式：為子系統中的一組接口提供一個一致的界面，其定義了一個高層接口，這個接口使得這一子系統更加容易使用。
使用場景：
需要復雜的子系統提供一個簡單的接口。
客戶與抽象的實現類中存在若干依賴。
子系統分層是必要的或架構要求的情況下。
享元模式：運用共享技術有效地支持大量細粒度的對象。
使用場景：
系統需要存在大量的對象而共享某些本質的、不變的信息。
對象可以同時用于多個環境下。
在每個實例下，享元可以作為一個獨立的對象。
組合模式：組合多個對象形成樹形結構，以表示整體－部分的結構層次。組合模式對單個對象和組合對象的使用具有一致性。
使用場景：
當需要表示一個對象的整體或部分層次。
想讓客戶忽略不同對象的層次變化。
對象的結構是動態的并且復雜程度不一樣，但客戶需要一致的處理它們。
代理模式：代理模式（Proxy）的目標是為其他對象提供一個代理或地方以控制對這個對象的訪問。當客戶向代理對象第一次提出請求時，代理實例化真實對象，并且將請求傳給它，以后所有客戶請求都經由代理傳給真實對象。
使用場景：
虛擬代理、遠程代理、安全代理、聰明引用。
行為型：
模版模式：定義一個操作中算法的骨架，將一些步驟的執行延遲到其子類中。
使用場景：
需要將相同的算法放在一個類中，將算法變化的部分放在子類中實現。
子類公共的算法應該放在一個公共類中，避免代碼重復。
責任鏈模式：使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞請求，直到有一個對象處理它為止。
使用場景：
超過一個對象能夠處理客戶請求并且到底哪個對象處理。
一個請求可以發布到多個對象但它的接收都是不清晰。
可以動態指定一組對象處理請求。
命令模式：將一個請求封裝成一個對象，因此可以參數化多個客戶的不同請求，將請求排除，記錄請求日志，并支持撤消操作。
使用場景：
需要與動作有關的對象來作為參數。
需要在不同的時間創建請求，生成請求隊列，執行請求。
需要支持取消、保存或處理事務的功能。
需要支持宏命令。
解釋器模式：給出一種語言，定義這種語言的文法的一種表示，定義一個解釋器，用它來解釋使用這種語言的句子。
使用場景：
語言的文法需要擴展。
迭代器模式：提供一種方法可以訪問聚合對象，而不用暴露這個對象的內部表示。
使用場景：
需要遍歷訪問聚集中的對象而不能暴露聚集的內部結構。
允許對聚集的多級遍歷訪問而不會相互受影響。
提供一個一致的接口來遍歷訪問聚集中不同的結構。
中介模式：定義一個對象封裝一系列多個對象如何相互作用，使得對象間不需要顯式地相互引用，從而使其耦合更加松散，并且還讓我們可以獨立變化多個對象相互作用。
使用場景：
一組對象復雜地相互通信但其方法是定義明確的。
若干個對象需要定義方法又不需要子類實現。
觀察者模式：定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時, 所有依賴于它的對象都得到通知并被自動更新。
使用場景：
一個對象的變化請求需要其他對象也變化，并且其他要變化對象的數量不明確。
一個對象需要通知其他對象而不需要掌握其他對象的識別方法。
備忘模式：在不破壞封閉的前提下，捕獲并保存一個對象的內部狀態，這樣可以將對象恢復到原先的狀態。
使用場景：
對象狀態的備忘足以使對象可以完全恢復到原來的狀態。
狀態模式：允許一個對象在其內部狀態改變的時候改變行為。
使用場景：
對象的行為于它的狀態，并且它必須可以根據它的狀態而改變行為。
系統存在大量的條件判斷語句。
策略模式：定義一系列算法，將每個算法封裝起來，并讓他們可以相互替換。策略模式讓算法獨立于使用它的客戶而變化。
使用場景：
多個類的分別只是在于行為不同。
需要對行為的算法作很多變動。
客戶不知道算法要使用的數據。
訪問者模式：分離對象數據結構與行為的方法，通過這種分離，可以為一個已存在的類或類群增加新的操作而無需為它們作任何修改。
使用場景：
一個對象的結構包含多個不同接口的對象，并且需要根據具體對象作不同的處理。
對結構中的對象有很多不同且沒有聯系的處理，因此需要避免操作將類分離。
類中定義的對象結構很少改變，但你需要經常地定義處理結構的新操作。