2011年軟考系統(tǒng)架構(gòu)設(shè)計師學習筆記第七章

字號:

2011年軟考系統(tǒng)架構(gòu)設(shè)計師學習筆記第七章

    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)上定義新的操作。