每一種都有對應理解的相關代碼示例 → Git原碼
一. GOF-23 模式分類
從目的來看
• 創建型（Creational）模式：將對象的部分創建工作延遲到子類或者其他對象，從而應對需求變化為對象創建時具體類型實現引來的沖擊。
• 結構型（Structural）模式：通過類繼承或者對象組合獲得更靈活的結構，從而應對需求變化為對象的結構帶來的沖擊。
• 行為型（Behavioral）模式：通過類繼承或者對象組合來划分類與對象間的職責，從而應對需求變化為多個交互的對象帶來的沖擊。
從范圍來看
• 類模式處理類與子類的靜態關系。
• 對象模式處理對象間的動態關系。
二. 重構獲得模式（Refactoring to Patterns）
-
面向對象設計模式是“好的面向對象設計”，所謂“好的面向對象設計”指是那些可以滿足 “應對變化，提高復用”的設計 。
-
現代軟件設計的特征是“需求的頻繁變化”。設計模式的要點是“尋找變化點，然后在變化點處應用設計模式，從而來更好地應對需求的變化”.“什么時候、什么地點應用設計模式”比“理解設計模式結構本身”更為重要。
-
設計模式的應用不宜先入為主，一上來就使用設計模式是對設計模式的最大誤用。沒有一步到位的設計模式。敏捷軟件開發實踐提倡的“Refactoring to Patterns”是目前普遍公認的最好的使用設計模式的方法。
三. 重構關鍵技法
-
靜態 → 動態
-
早綁定 → 晚綁定
-
繼承 → 組合
-
編譯時依賴 → 運行時依賴
-
緊耦合 → 松耦合
四. 從封裝變化角度對模式分類
組件協作：
Template Method
Observer / Event
Strategy
單一職責：
Decorator
Bridge
對象創建:
🔗 對象創建（FactoryMethod - AbstractFactory - Prototype - Builder）
Factory Method
Abstract Factory
Prototype
Builder
對象性能：
Singleton
Flyweight
接口隔離:
Façade
Proxy
Mediator
Adapter
狀態變化：
Memento
State
數據結構：
Composite
Iterator
Chain of Responsibility
行為變化：
Command
Visitor
領域問題：
Interpreter
什么時候不用模式
- 代碼可讀性很差時
- 需求理解還很淺時
- 變化沒有顯現時
- 不是系統的關鍵依賴點
- 項目沒有復用價值時
- 項目將要發布時
經驗之談
- 不要為模式而模式
- 關注抽象類 & 接口
- 理清變化點和穩定點
- 審視依賴關系
- 要求Framework 和 Application 的區隔思維
- 良好的設計是演化的結果
設計模式成長之路
- “手中無劍，心中無劍” ： 見模式而不知
- “手中有劍，心中無劍” ：可以識別模式，作為應用開發人員模式
- “手中有劍，心中有劍” ： 作為框架開發人員為應用設計某些模式
- “手中無劍，心中有劍” ： 忘掉模式，只有原則