一個目標

管理變化，提高複用

兩種手段

分解 vs 抽象

八大原則

依賴倒置原則

開放封閉原則

單一指責原則

Liskov替換原則

介面隔離原則

物件組合優於繼承

封裝變化點

面向介面程式設計

原則比具體的設計模式更重要，內化原則

重構技法

靜態 —> 動態

早繫結 —> 晚繫結

繼承 —> 組合

編譯時依賴 —> 執行時依賴

緊耦合 —> 鬆耦合

從封裝變化的角度對模式分類

像Builder,Mediator等一些設計模式在平時用的不多，也有些是因為C++在語言特性上的進步使得某些模式的使用價效比不高。

C++物件模型

以上的設計模式最後都殊途同歸，如第三種物件模型，都是通過一個指標指向一個多型物件表達靈活性。

關注變化點與穩定點

當軟體中所有部分都處於變化之中，就沒有設計模式能解決，當軟體中所有部分都穩定，也沒有必要使用設計模式。當然這兩種極端的情況很少會出現，一般的軟體的穩定與變化是呈正態分佈的，

什麼時候不用設計模式

程式碼可讀性很差時

需求理解還很淺時

變化沒有顯現時

不是系統的關鍵依賴點

專案沒有複用價值時

專案將要釋出時

程式碼可讀性是軟體最基礎的質量保證，模式是在基礎工作做好之後才用的。

經驗之談

不要為模式而模式

關注抽象類&介面

理清變化點和穩定點

審視依賴關係

要有Framework和Application的區隔思維

良好的設計是演化的結果

設計模式成長之路

“手中無劍，心中無劍”：見模式而不知

“手中有劍，心中無劍”：可以識別模式，作為應用開發人員使用模式

“手中有劍，心中有劍”：作為框架開發人員為應用設計某些模式

“手中無劍，心中有劍”：忘掉模式，只有原則