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