網上查到的設計模式有23種，通過歸納去認識他們也是一種不錯的視角。
我這邊不按照主流的觀點去劃分為創建型、結構型、行為型三大類，我只歸納為創建型（Creational Class）、簡單功能場景（Simple Method Class）、複雜功能場景（Complex Method Class）三大類。原因是結構、行為這種詞本身就比較泛，而模式本身就是一種比較交叉融合的狀態，所以根據我的理解，我主觀性的重新劃分，當然只是為了讓我理解和思考。

其實程式設計模式里，大多數的考慮初衷都是為了面向未來未知情況，在當前就先規劃做好擴展方式，方便能讓未來使用者使用方便的代碼結構。
也有能節省資源的設計模式、方便解耦的設計模式...

Creational Class

幫助機器（系統）節省資源的創建對象模式：

• Singleton Pattern
• Flyweight Pattern
• Prototype Pattern（也叫克隆模式）

面對未來未知，由外部提供需求來創建對象模式，如下幾種應該說在各大框架里能常看到：

• Simple Factory
• Factory Methoed Pattern
• Abstract Factory Pattern
  當抽象工廠模式只生產一個產品時，和工廠方法模式沒啥區別。當它生成一組或多個產品時，才有所區別。
• Buidler Pattern

Simple Method Class

Simple Method Class就是非常好理解的設計模式，他們往往都能對應現實生活中某些機構、某種職業的運作模式，所以非常好理解。

• Facade Pattern（也叫前臺接待模式）
• Template Pattern
  模版模式也是一種應對未來未知情況的解決方案，部分可知，部分不可知；
• 觀察者模式
  一種一對多的關係，當一個類的狀態發送改變，就通知所有依賴（有關係）的類；
• 狀態模式/策略模式
  將狀態封裝成一個類，不同狀態的類，會有不同的行為。 狀態模式和策略模式是一樣的。
• 中介者模式
  為瞭解耦各個類，只通過中介者去通信，有點繞。
• Proxy Pattern
  • 代理對象充當了客戶端和目標對象之間的中介，從而可以在訪問目標對象時添加額外的邏輯；
  • 代理對象持有一個真實主題的引用，併在需要時創建或獲取真實主題對象；
  • 代理對象在調用真實主題之前或之後，執行一些額外的操作，例如許可權驗證、緩存、日誌記錄等。
• 責任鏈模式
  責任鏈模式很容易理解（想想在公司請假的流程，員工發起，組長審批——>部門領導審批——>HR審批——>BOSS...）
  它也用到遞歸，控制不好就容易死迴圈；

下麵這些個模式一般不在程式設計的時候考慮，並且新程式在設計初期就不應該出現如下情況，會把程式搞複雜！反而，它們更適合運用在程式維護階段，程式已經運行起來，在不大規模的重構之前，也沒有好辦法的時候才考慮使用。當然還有一種情況，就是你使用別人寫好的介面，調用別人的SDK，你是無法修改調用的介面方法的，你能做的就是自己封裝多一層中間層，下麵是幾種不同場景介紹：

• Adapter Pattern（適配器模式）
  當需要使用一個已存在的類，但其介面與要求的介面不匹配時。
• Decorator Pattern（裝飾者模式）
  • 用於在不修改現有對象結構的前提下，動態地給對象添加額外的功能；
  • Decorator 和 Proxy有相似的地方，就是都是給現有類.方法增加額外功能，不同點在於Decorator是不修改現有對象結構。

Complex Method Class

下麵這幾個模式就有點繞了，只能自己多思考了，無他法。

• Composite Pattern
  需要用到遞歸，控制不好就容易死迴圈；
• Bridge Pattern
• 迭代器模式
  解耦思想，將行為和對象分離；
• 備忘錄模式
  在不暴露對象內部狀態的情況下保存和恢復對象的狀態。
  為了完成這個保護和恢復功能涉及的類比較多，就容易複雜。
• 命令模式
  也是一種解構思想，將行為和數據結構分離；
  命令模式還有一個撤銷操作，和備忘錄有相似；
• 訪問者模式
  • TODO
• 解釋器模式
  • TODO