設計模式：
把不變的抽象出來，把變化的放到實現

管理軟體的複雜度
軟體設計複雜的根本原因：變化，變化是複用的天敵
軟體設計的目標：複用
面向物件設計的最大的優勢：抵禦變化
關鍵詞:抽象

設計原則：
1. 依賴倒置原則（DIP）
高層模組（穩定）不應該依賴於底層模組（變化），二者都應該依賴於抽象（穩定）。
抽象（穩定）不應該依賴於實現細節（變化），實現細節應該依賴於抽象（穩定）。
2. 開放封閉原則（OCP）
對擴充套件開放，對修改封閉。
類模組應該是可擴充套件的，但是不可修改。
3. 單一職責原則（SRP）
一個類應該僅有一個引起它變化的原因。
變化的方向隱含著類的責任。
4. Liskov替換原則（LSP）
子類必須能夠替換它們的基類（IS-A）
繼承表達型別抽象。
5. 介面隔離原則（ISP）
不因該強迫客戶程式依賴他們不應的方法。
介面應該小而完備。
6. 優先使用物件組合，而不是類繼承
類繼承通常為“白箱複用”，物件組合通常為“黑箱複用”。
類繼承在某種程度上破壞了封裝性，子類父類耦合度高。
而物件組合則只要求被組合的物件具有良好定義的介面，耦合度低。
7. 封裝變化點
使用封裝來建立物件之間的分界層，讓設計者可以在分界層的一側進行修改，而不是對另一側產生不良的影響，從而實現層次間的鬆耦合。
8. 針對介面程式設計，而不是實現程式設計
不將變數型別宣告為某個特定的具體類，而是宣告為某個介面。
客戶程式無需獲知物件的具體型別，只需要知道物件所具有的介面。
減少系統中各部分的依賴關係，從而實現“高內聚、鬆耦合”的型別設計方案。

面向介面設計
產業強盛的標誌：介面標準化

好的面向物件設計：應對變化，提高複用

設計模式的要點：尋找變化點，然後在變化點應用設計模式，從而更好的應對需求的變化。 “什麼時候、什麼地點應用設計模式”比“理解設計模式結構本身”更重要。

看問題： 時間軸（考慮未來的變化），不要靜態看問題

重構關鍵技法
靜態-》動態
早繫結-》晚繫結
繼承-》組合
編譯時依賴-》執行時依賴
緊耦合-》鬆耦合

“元件協作”模式
模板方法
策略
觀察者

“單一職責”，模式
裝飾器
橋接

"物件建立"模式
工廠方法
抽象工廠
原型
建造者

“物件效能”模式
單例
享元

“介面隔離”模式
門面
代理
介面卡
中介者

"狀態變化"模式
狀態
備忘錄

“資料結構”模式
組合
迭代器
職責鏈

”行為變化“模式
命令
訪問器
解析器

”領域規則“模式
直譯器

總結：
一個目標：管理變化，提高複用
兩種手段：分解 VS. 抽象
八大原則
重構技法
從封裝變化角度對模式分類
物件模型：
class A{
IB b;
}
關注變化點和穩定點
什麼時候不用模式：
程式碼可讀性差時
需求理解還很淺時
變化沒有顯現時
不是系統的關鍵依賴點
專案沒有複用價值時
專案將要釋出時
經驗之談：
不要為了模式而模式
關注抽象類 & 介面
理清變化點和穩定類
審視依賴關係
要有Framework和Application的區隔思想
良好的設計時演化的結果

設計模式成長之路：
”手中無劍，心中無劍“：見模式而不知
”手中有劍，心中無劍“：可以識別模式，作為應用開發人員使用模式
”手中有劍，心中有劍“：作為框架開發人員為應用設計某些模式
”手中無劍，心中有劍“：忘掉模式，只有原則