閱讀指南：
精讀一章內容，手工輸入一章程式碼（注1），與書中描述的思想進行印證，實在搞不懂就放過吧。設計模式絕對不會一次就看懂的。
這本書對於理解設計模式很有幫助，就是例子不太符合中國人的思維模式，但是堅持下去肯定會搞明白的。
全書精華：
1. Chap12的Ducks，通過一點點重構Ducks程式，將模式一個個加入其中，幫助對模式的深入理解。
2. Chap12的DJView，通過一個完整的MVC程式，將Observer、Strategy、Composite以及Adapter模式用架構層面的設計整合起來，不僅可以更好地理解單個模式，還可以理解MVC模式。
儘可能對每個模式寫出自己的總結
- Strategy（策略模式）：定義一組演算法類，用於執行過程中替換演算法。
- 封裝變化
- 多用組合，少用繼承
- 多針對介面程式設計，少針對實現程式設計
- Observer（觀察者模式）：定義一個主題和一組觀察者，可以在主題變化時通知訂閱了主題的觀察者。
- Strategy封裝的是函式呼叫的演算法。
- Observer封裝的是傳遞資料的內容。
- 互動物件之間強內聚、鬆耦合。
- Decorator（裝飾模式）：本質不變，外面增加一層層裝飾。例如：Stream的包裝。
- 設計的類，禁止修改，允許擴充套件。
- 不採用繼承的方式來擴充套件功能。
- Factory（工廠模式）：所有的工廠都是用來封裝物件的建立。
- Simple Factory（簡單工廠）：將業務邏輯與物件建立操作分離開。
- Factory Method（工廠方法）：把物件的建立工作委託給子類的工廠方法。
- Abstract Factory（抽象工廠）：把物件的建立工作委託給實現了介面的工廠方法。
- 依賴於抽象，而不依賴於具體的類。
- Singleton（單例模式）：通過禁止其他物件對自己例項化，而改由自己的靜態方法對自己例項化，確保一個類只有一個物件。
- Command（命令模式）：解耦呼叫者與執行者之間的關係，相互之間的聯絡通過命令物件完成，呼叫者只對呼叫物件的execute()方法發出請求。
- 改造已有系統介面，使異構系統也可透明地相互呼叫。
- Adapter（介面卡）：將一個類的介面轉換成客戶期望的另一個介面。例：資料庫連線
- Facade（門面模式）：將一組介面轉換成客戶期望的單一介面。例：裝置驅動程式
- 最小知識原則：呼叫其他方法時，涉及的物件越少越好。
- 物件呼叫自己的方法
- 物件呼叫作為引數傳入的物件的方法
- 物件呼叫自己的方法建立的物件或例項的方法
- （以上三點強調：不要呼叫其他方法返回的物件的方法）
- 物件呼叫自身元件的方法
- Template（模板模式）：封裝演算法，在一個方法中定義一個演算法的框架，而將具體的實現委託給子類。框架中呼叫的方法為鉤子，從而超類控制一切，子類實現鉤子等待超類呼叫。
- 好萊塢原則：別找我，我會去找你。
- Collections（集合）：
- Iterator（迭代器）：遍歷集合而無須暴露集合的實現
- Composite（組合模式）：可以將物件的集合和單個物件組合在一起。
- 類應該只有一個改變的理由。
- State（狀態模式）：將狀態封閉為物件，將行為封裝成方法；新的狀態生成新物件，新的行為生成新的方法。
- 行為不變，狀態改變用State
- 行為改變，狀態不變用Strategy
- Proxy（代理模式）：採用建立代理物件的方式控制客戶端對具體物件的訪問。
- 遠端代理管理客戶端和遠端物件之間的互動；
- 虛擬代理控制例項化開銷大的物件；
- 保護代理控制客戶端對具體物件的訪問。
- Compound（複合模式）：MVC-Model，View，Controller
- Model與View之間使用Observer模式。Model是Subject，View是Observer，當Model改變時通知View發生改變。View只從Model中獲取資料（例如：呼叫Model的getXXX()方法），不修改Model的資料（例如：不呼叫Model的SetXXX()方法），不操作Model的行為（例如：不呼叫Model的行為方法）。
- Controller與View之間是Strategy模式。View只對Controller的介面程式設計，不與具體的Controller實現耦合，從而可以面對不同的Controller實現不同的行為。
- View自身使用Composite模式。
- 還可以使用Adapter模式，使已經存在的Controller和View與Model適配。
注：
1. 原始碼一定要去下載，書上的程式碼內容不夠
2. 設計模式並不複雜，這23種模式的理解之一就是介紹如何針對介面程式設計
程式設計思路的演變：針對函式程式設計→針對物件程式設計→針對介面程式設計