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