大名鼎鼎的GOF的設計模式是最著名的一本里程碑的作品
=模式分類=
=模式之間的關系=
=如何應用模式=
DP中的引言說得很好,如何應該模式來解決設計問題
* 尋找合適的對象
對象包括數據和操作, 對象在收到請求(或消息)后, 執行相應的操作
客戶請求是使對象執行操作的唯一方法, 操作又是對象改變內部數據的唯一方法
(這就是封裝的意義,之所以強調對象的成員應該是私有的原因)
OOD最困難的部分就是將系統分解成對象集合,因為要考慮許多因素:
封裝,粒度,信賴關系,靈活性,性能,演化,復用等等,它們之間也互相有所影響或沖突.
設計模式可以幫助我們確定那些并不明顯的抽象和描述這些抽象的對象,如Strategy, State,etc.
==決定對象的粒度==
如何決定對象的大小,數目以及范圍呢, 設計模式亦有所幫助:
Facade 描述了怎樣用對象表示完整的子系統
Flyweight
Abstact Factory
Builder
Visitor
Command
==指定對象接口==
對象接口描述了該對象所能接受的全部請求的集合, 也就是它能夠提供哪些服務(方法)
當給對象發送請求時, 所引起的具體操作既與請求本身有關,又與接受對象有關
支持相同請求的不同對象可能對請求激發的操作有不同的實現(動態綁定和多態)
而設計模式通過確定接口的主要組成部分及經接口發送的數據類型, 來幫助你定義接口.
DP也許還會告訴你接口中不應包括哪些東西, 比如Memento模式所規定的接口
DP也指定了接口之間的關系,特別地,它常要求一些類具有相同或相似的接口,或對一些類的接口作出一些限制
如Decorator, Proxy模式要求修飾/代理對象和被修飾/受代理的對象接口保持一致
Visitor模式中Vistor接口必須反映能訪問的對象的所有類
==描述對象的實現==
* 類繼承還是接口繼承呢
* 針對接口編程,而不是針對實現編程
==運用復用機制==
1.優先使用對象組合,而不是類繼承
2.委托
3.繼承和泛型的比較
==關聯運行時刻和編譯時刻的結構==
==設計應支持變化==
* 設計中常出現的問題
** 通過顯式地指定一個類來創建對象
*** Factory , Prototype
** 對特殊操作的依賴
*** Chain of Reponsibility, Command
** 對硬件和軟件平臺的依賴
*** Abstract Factory, Bridge
** 對對象表示或實現的依賴
** 算法依賴
** 緊耦合
*** Abstract Factory, command, facade, mediator, observere,chain of responsibility
** 通過生成子類來擴充功能
*** Bridge, Chain of Reponsibility, composite, Decorator, Observer, Strategy
** 不能方便地對類進行修改
*** Adapter, Decorator, visitor
=如何選擇設計模式=
* 考慮設計模式是如何解決設計問題的
* 瀏覽模式的意圖部分
* 研究模式怎樣互相關聯
* 研究目的相似的模式
* 檢查重新設計的原因
* 考慮你的設計中哪些是可變的
=怎樣使用設計模式=
* 大致瀏覽一遍模式
* 回頭研究結構部分
* 看代碼示例部分
* 選擇模式參考者的名字, 使它們在應用上下文中有意義
* 定義類
* 定義模式中專用于應用的操作名稱
* 實現執行模式中責任和協作的操作