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