2011年軟考系統(tǒng)架構(gòu)設(shè)計(jì)師學(xué)習(xí)筆記第七章
7.1 設(shè)計(jì)模式概述
重復(fù)遇到的典型問題，描述這些共同問題和解決這些問題的方案 就形成了所謂的模式。
7.1.1 設(shè)計(jì)模式的歷史
模式分為幾個(gè)部分：
特定的情景(Context)，指模式在 何種情況下發(fā)生作用;
動機(jī)(System of Force)，指問題或預(yù)期的目標(biāo);
解決方案(Solution)，平衡各動機(jī) 或解決所闡述問題的 構(gòu)造或配置。
每個(gè)模式描述了一個(gè)在某種特定情境下不斷重復(fù)發(fā)生的問題，以及解決該問題解決方案的核心所在。
7.1.2 為什么要使用設(shè)計(jì)模式
面向?qū)ο笤O(shè)計(jì)時(shí)需要考慮 封裝性、力度大小、依賴關(guān)系、靈活性、可重用性 等。
1、簡化并加快快設(shè)計(jì)
無需從底層做起，重用成功的設(shè)計(jì)，節(jié)約開發(fā)時(shí)間，提高軟件質(zhì)量。
2、方便開發(fā)人員之間的通信
可以更準(zhǔn)確地 描述問題 及 問題的解決方案，使解決方案具有一致性。
3、降低風(fēng)險(xiǎn)
4、有助于轉(zhuǎn)到面向?qū)ο蠹夹g(shù)
開發(fā)人員對新技術(shù)往往會有抵觸或排斥心理，對成熟的設(shè)計(jì)模式具有以下特性：
1.巧妙。
2.通用，不依賴于 系統(tǒng)、語言、領(lǐng)域。
3.不僅僅停留在理論上。
4.簡單。
5.可重用。
6.面向?qū)ο蟆?/p>
7.1.3 設(shè)計(jì)模式的組成元素
1、模式名，簡潔地描述了 模式的本質(zhì)，可以幫助我們思考。
2、問題或意圖，解釋了設(shè)計(jì)問題和問題存在的前因后果，可能描述了特定的設(shè)計(jì)問題。
3、情景，告訴我們該模式的適用性。
4、動機(jī)，描述相關(guān)的動機(jī)和約束，通常需要對各期望的目標(biāo)進(jìn)行有限排序，動機(jī)闡明了問題的復(fù)雜性，定義了在相互沖突時(shí)所采取的各種權(quán)衡手段。
5、解決方案，因?yàn)槟Ｊ骄拖褚粋€(gè)模板，所以解決方案并不描述一個(gè)特定而具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問題的 抽象描述 和怎樣用一個(gè) 具有一般意義的 元素組合。
6、示例，幫助讀者理解模式的具體使用方法。
7、結(jié)果情景，闡述了模式后續(xù)狀態(tài)和副作用。
8、基本原理，解釋該模式 如何、為何 能解決當(dāng)前問題。
9、相關(guān)模式，包括 靜態(tài)的 和 動態(tài)的，遷到模式、后續(xù)模式、替代模式。
10、已知應(yīng)用，通常好的模式前面都有一個(gè)摘要，提供簡短的總結(jié)和概述，為模式描繪出一個(gè)清晰的圖畫，提供有關(guān)該模式能夠解決問題的快速信息。
新技術(shù)可能帶來的效果持懷疑態(tài)度。
模式應(yīng)該說明它的目標(biāo)讀者，以及對讀者有哪些知識要求。
7.1.4 設(shè)計(jì)模式的分類
軟件模式 主要可分為 設(shè)計(jì)模式、分析模式、組織和過程模式等。
設(shè)計(jì)模式主要用于 得到簡潔靈活的 系統(tǒng)設(shè)計(jì)。
按設(shè)計(jì)模式的目的劃分，創(chuàng)建型、結(jié)構(gòu)型、行為型;
按設(shè)計(jì)模式范圍劃分，類設(shè)計(jì)模式、對象設(shè)計(jì)模式。
1、創(chuàng)建型模式，對對象實(shí)例化過程的 抽象，采用抽象類所定義的接口，封裝了對象如何創(chuàng)建、組合等信息。
2、結(jié)構(gòu)型模式，如何組合已有的類和對象 以及獲得更大的結(jié)構(gòu)。
3、行為型模式，不僅描述對象或類的模式，還描述它們之間的通信模式，特別是描述一組對等的對象怎樣互相協(xié)作 完成其中任一對象無法單獨(dú)完成的任務(wù)。
7.2 設(shè)計(jì)模式實(shí)例
7.2.1 創(chuàng)建性模式
通過該了的子類來創(chuàng)建對象的。但是，這可能會 限制在系統(tǒng)內(nèi)創(chuàng)建對象的類型或數(shù)目。
1、Abstract Factory 模式
在不指定具體類的情況下，為創(chuàng)建一些列 相關(guān) 或 相互依賴的對象提供了接口。
提供了一個(gè)可以 確定合適的具體類 的抽象類。
優(yōu)點(diǎn)：
可以與具體類分開。
更容易在產(chǎn)品系列中轉(zhuǎn)換。
提高了產(chǎn)品間的一致性。
以下情況應(yīng)該使用 Abstract Factory 模式：
系統(tǒng)獨(dú)立于產(chǎn)品的 創(chuàng)建、組成、表示。
系統(tǒng)配置成 具有多個(gè)產(chǎn)品的 系列。
相關(guān)產(chǎn)品對象系列 是共同使用的，而且必須確保這一點(diǎn)。
你希望提供產(chǎn)品的類庫，只開放其接口。
2、Builder 模式
將復(fù)雜對象的 構(gòu)件與表示 相分離，相同的構(gòu)造過程可以創(chuàng)建不同的對象，通過只指定對象的 類型和內(nèi)容。
一次就可以創(chuàng)建所有的復(fù)雜對象，而其他模式一次就只能創(chuàng)建一個(gè)對象。
優(yōu)點(diǎn)：
可以對產(chǎn)品內(nèi)部表示進(jìn)行改變。
將構(gòu)造代碼與表示代碼相分離。
以下情況應(yīng)該使用 Builder 模式：
算法獨(dú)立于 組成對象。
構(gòu)造過程必須允許已構(gòu)件對象有不同表示。
3、Factory Method 模式
實(shí)例化工作交給其子類，可以在不修改代碼的情況下引入新類，因?yàn)樾骂愔粚?shí)現(xiàn)了接口。
優(yōu)點(diǎn)：
代碼只處理接口，因此可以使用任何實(shí)現(xiàn)了接口的類。
在類中創(chuàng)建對象比直接在客戶端創(chuàng)建要更加靈活。
以下情況中，應(yīng)該使用 Factory Method 模式：
類不能預(yù)料它必須創(chuàng)建的對象的類。
類希望其子類指定要創(chuàng)建的對象。
類將責(zé)任轉(zhuǎn)給某個(gè)幫助子類，而用戶希望定位那個(gè)被授權(quán)的幫助子類。
4、Prototype 模式
只要將對象類定義成能夠復(fù)制自身就可以實(shí)現(xiàn)。
優(yōu)點(diǎn)如下：
可以在運(yùn)行時(shí) 添加或刪除產(chǎn)品。
通過改變值 指定新對象。
通過改變結(jié)構(gòu) 制定新對象。
減少子類的生成和使用。
可以用類 動態(tài)地配置 應(yīng)用程序。
以下情況中，應(yīng)該使用Prototype 模式：
運(yùn)行時(shí)，指定需要實(shí)例化的類，例如動態(tài)載入。
避免構(gòu)建與產(chǎn)品的類層次結(jié)構(gòu)相似的 工廠類層次結(jié)構(gòu)。
5、Singleton 模式
確保 一個(gè)類只有一個(gè)實(shí)例，并且提供全局訪問入口，確保使用這個(gè) 實(shí)例 所有的對象 使用相同的實(shí)例。
優(yōu)點(diǎn)：
對單個(gè)實(shí)例的受控訪問。
命名空間的減少。
允許改進(jìn)操作和表示。
允許改變數(shù)目的實(shí)例。
比類操作更靈活。
7.2.2 結(jié)構(gòu)性模式
機(jī)構(gòu)性模式 控制 較大部分之間的 關(guān)系。
它將以不同的方式 影響應(yīng)用程序。
允許在補(bǔ)充寫代碼或自定義代碼的情況下 創(chuàng)建系統(tǒng)。
具有增強(qiáng)的 重復(fù)使用性和應(yīng)用性能。
1、Adapter 模式
可以充當(dāng)兩個(gè)類之間的媒介，可以轉(zhuǎn)換一個(gè)類的接口，被另外一個(gè)類使用，使得具有不兼容接口的類能夠系統(tǒng)使用。
優(yōu)點(diǎn)：
允許多個(gè)不兼容的對象 進(jìn)行交互和通信。
提高已有功能的重復(fù)使用性。
以下情況，應(yīng)該使用 Adapter 模式：
要使用已有類，而該類接口與所需的接口并不匹配。
要創(chuàng)建可重用的類，該類可以與 不相關(guān) 或 未知類 進(jìn)行協(xié)作。
要在一個(gè) 不同于已知對象接口的接口環(huán)境中 使用對象。
必須要進(jìn)行多個(gè)源之間的接口轉(zhuǎn)換的時(shí)候。
2、Bridge模式
將一個(gè)復(fù)雜的組件 分成兩個(gè)獨(dú)立的 但又相關(guān)的 繼承層次結(jié)構(gòu)：功能性抽象和內(nèi)部實(shí)現(xiàn)。
優(yōu)點(diǎn)：
接口與實(shí)現(xiàn)相分離。
提高了可擴(kuò)展性。
對客戶端隱藏了實(shí)現(xiàn)的細(xì)節(jié)。
以下情況中，應(yīng)該使用 Bridge 模式：
避免在抽象及其實(shí)現(xiàn)之間 存在***的綁定。
抽象及其實(shí)現(xiàn) 可以使用子類進(jìn)行擴(kuò)展。
抽象的實(shí)現(xiàn)被改動 不用重新編譯代碼。
3、Composite 模式
創(chuàng)建樹形層次結(jié)構(gòu)來改變復(fù)雜性。
優(yōu)點(diǎn)：
定義了由 主要對象 和 符合對象 組成的類層次結(jié)構(gòu)。
添加新的組件類型更加簡單。
結(jié)構(gòu)的靈活性和可管理性的接口。
以下情況中，應(yīng)該使用 Composite 模式：
想要表示對象的整個(gè) 或者部分的層次結(jié)構(gòu)。
想要客戶端能夠忽略符合對象和單個(gè)對象之間的差異。
結(jié)構(gòu)可以具有任何級別的復(fù)雜性，而且是動態(tài)的。
4、Decorator 模式
不修改對象外觀和功能的情況下 添加或刪除對象功能。
優(yōu)點(diǎn)：
比靜態(tài)繼承具有更大的靈活性。
避免了特征裝載的類 處于層次結(jié)構(gòu)的 過高級別。
簡化了編碼。
改進(jìn)了對象的擴(kuò)展性。
在以下情況中，應(yīng)該使用 Decorator 模式：
在單個(gè)對象中 動態(tài)并且透明地 添加責(zé)任，不會影響其他對象。
以后可能要修改的對象中添加責(zé)任。
無法通過靜態(tài)子類化實(shí)現(xiàn)擴(kuò)展時(shí)。
5、Facade 模式
為子系統(tǒng)中的一組接口 提供了一個(gè)統(tǒng)一的接口。更容易使用子系統(tǒng)的高級接口。
優(yōu)點(diǎn)：
在不減少系統(tǒng)所提供的選項(xiàng)的情況下，為復(fù)雜系統(tǒng)提供了簡單接口。
屏蔽了子系統(tǒng)組件。
提高若耦合度。
將客戶端請求轉(zhuǎn)換后 發(fā)送給能夠處理這些請求的 子系統(tǒng)。
以下情況中，應(yīng)使用 Facade 模式：
為復(fù)雜的子系統(tǒng)提供簡單的接口。
客戶端和抽象的實(shí)現(xiàn)類中 存在許多依賴關(guān)系。
想要對子系統(tǒng)進(jìn)行分層。
6、Flyweight 模式
通過共享對象 減少對象數(shù)目。
通過共享一個(gè)接口來避免使用多個(gè)具有相同信息的實(shí)例 所帶來的開銷。
優(yōu)點(diǎn)：
減少了要處理的對象數(shù)目。
如果對象能夠持續(xù)，可以減少內(nèi)存和存儲設(shè)備。
以下情況中，應(yīng)該使用 Flyweight 模式：
應(yīng)用程序使用大量的對象。
由于對象數(shù)目巨大，導(dǎo)致很高的存儲開銷。
不依賴于對象的身份。
7.2.3 行為性模式
行為性模式 影響 系統(tǒng)的 狀態(tài)、行為流。
簡化、優(yōu)化 并且 提高應(yīng)用程序的 可維護(hù)性。
1、Chain of Responsibility 模式
在系統(tǒng)中建立一個(gè)鏈，在首先接收到它的級別處 被處理，或者定位到可以處理它的對象。
優(yōu)點(diǎn)：
降低了耦合度。
增加面向?qū)ο笾贫ㄘ?zé)任的 靈活性。
類的集合可以作為一個(gè)整體。
以下情況中，應(yīng)該使用 Chain of Responsibility 模式：
多個(gè)對象可以處理一個(gè)請求，而其處理器卻是未知的。
在不指定確切的 請求接受對象的情況下，向幾個(gè)對象中的 一個(gè) 發(fā)送請求。
動態(tài)地指定能夠處理請求的對象集。
2、Command 模式
在對象中封裝了請求。
優(yōu)點(diǎn)：
將調(diào)用操作的對象 與 知道如何完成該操作的對象 相分離。
更容易添加新指令，因?yàn)椴挥眯薷囊延蓄悺?/p>
以下情況中，應(yīng)該使用 Command 模式：
要通過執(zhí)行的動作 來 參數(shù)化對象。
在不同的時(shí)間 指定、排序、執(zhí)行 請求。
必須支持 Undo、日志記錄 或 事務(wù)。
3、Interpreter 模式
解釋定義其語法表示的語言，提供了語句解釋器。
優(yōu)點(diǎn)：
容易修改并擴(kuò)展語法。
更容易實(shí)現(xiàn)語法。
以下情況中，應(yīng)該使用 Interpreter 模式：
語言的語法比較簡單。
效率并不是最主要的問題。
4、Iterator 模式
為集合中的有序訪問提供了一致的方法，而該集合是獨(dú)立于基礎(chǔ)集合。
優(yōu)點(diǎn)：
支持集合的不同遍歷。
簡化了集合的接口。
以下情況中，應(yīng)該使用 Iterator 模式：
不開放集合對象內(nèi)部表示的前提下，訪問集合對象內(nèi)容。
支持集合對象的多重遍歷。
為遍歷集合中的不同結(jié)構(gòu) 提供了統(tǒng)一的接口。
5、Mediator 模式
通過引入一個(gè)能夠管理對象間消息分布的對象，簡化了系統(tǒng)中對象間的通信。提高了對象間的松耦合度，還可以獨(dú)立地 改變 其間的交互。
優(yōu)點(diǎn)：
去除對象間的影響。
簡化了對象間協(xié)議。
集中化了控制。
由于不再需要直接互傳消息，單個(gè)組件變得更加簡單，而且容易處理。
由于不再需要 包含邏輯 來處理組件間的通信，組件變得更加通用。
以下情況中，應(yīng)該使用 Mediator 模式：
對象集合需要以 一個(gè)定義規(guī)范但復(fù)雜的方式 進(jìn)行通信。
6、Memento 模式
保持對象狀態(tài)的“快照”(snapshot)，對象可以在不向外界公開其內(nèi)容的情況下 返回到它的最初狀態(tài)。
優(yōu)點(diǎn)：
保持封裝的完整性。
簡化了返回到初始狀態(tài)所需的操作。
以下情況中，應(yīng)該使用 Memento 模式：
必須保存對象狀態(tài)的快照，恢復(fù)狀態(tài)。
7、Observer 模式
定義了對象間 一到多 的依賴關(guān)系，當(dāng)對象改變狀態(tài)時(shí)，將自動通知 并 更新它所有的依賴對象。
優(yōu)點(diǎn)：
抽象了主題與 Observer 之間的耦合關(guān)系。
支持廣播方式通信。
以下情況中，應(yīng)該使用 Observer 模式：
對一個(gè)對象的修改 涉及對其他對象的修改，而且不知道有多少對象 需要進(jìn)行相應(yīng)修改。
對象應(yīng)該能夠 在不同假設(shè)對象標(biāo)識的前提下 通知其它對象。
8、State 模式
對象在內(nèi)部狀態(tài)變化時(shí)，變更其行為，并且修改其類。
優(yōu)點(diǎn)：
針對不同狀態(tài)來劃分行為，使?fàn)顟B(tài)轉(zhuǎn)換顯式進(jìn)行。
9、Strategy 模式
定義了一組能夠用來表示 可能行為集合的類。這些行為 可以在應(yīng)用程序中使用，來修改應(yīng)用程序功能。
優(yōu)點(diǎn)：
另一種子類化方法。
在類自身中定義了 每一個(gè)行為，減少了條件語句。
更容易擴(kuò)展模型。
以下情況中，應(yīng)該使用 Strategy 模式：
許多相關(guān)類 只是在行為方面有所區(qū)別。
需要算法的不同變體。
算法使用客戶端未知的數(shù)據(jù)。
10、Template Method 模式
不重寫方法的前提下 允許 子類重載部分方法 的方法。
將一些步驟由子類實(shí)現(xiàn)。
優(yōu)點(diǎn)：代碼重用的基礎(chǔ)技術(shù)。
以下情況中，應(yīng)該使用 Template Method 模式：
一次實(shí)現(xiàn)算法的不變部分，子類實(shí)現(xiàn)算法的可變行為。
11、Visitor 模式
不改變操作元素的類 的前提下 定義一個(gè)新操作。
優(yōu)點(diǎn)：
容易添加新操作。
集中相關(guān) 排除不相關(guān) 操作。
以下情況中，應(yīng)該使用 Visitor 模式：
包含許多具有不同接口的對象類，并且想要對這些 依賴具體類的對象進(jìn)行操作。
定義對象結(jié)構(gòu)的類很少被修改，但想要在此結(jié)構(gòu)上定義新的操作。
【編輯推薦】
