《軟件建模與實踐》課件-7-軟件設(shè)計模式-結(jié)構(gòu)型模式_第1頁
《軟件建模與實踐》課件-7-軟件設(shè)計模式-結(jié)構(gòu)型模式_第2頁
《軟件建模與實踐》課件-7-軟件設(shè)計模式-結(jié)構(gòu)型模式_第3頁
《軟件建模與實踐》課件-7-軟件設(shè)計模式-結(jié)構(gòu)型模式_第4頁
《軟件建模與實踐》課件-7-軟件設(shè)計模式-結(jié)構(gòu)型模式_第5頁
已閱讀5頁,還剩113頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

課程內(nèi)容7種結(jié)構(gòu)型模式的基本概念、特點及其適用環(huán)境課程目的了解結(jié)構(gòu)型模式的基本概念掌握7種結(jié)構(gòu)型模式的特點及其適用環(huán)境熟悉和掌握類圖及其他軟件結(jié)構(gòu)的表現(xiàn)和表達方式掌握在實際需求下應(yīng)用相關(guān)設(shè)計模式的方法重點適配器模式、組合模式難點享元模式結(jié)構(gòu)型模式(StructuralPattern)關(guān)注如何將現(xiàn)有類或?qū)ο蠼M織在一起形成更加強大的結(jié)構(gòu)不同的結(jié)構(gòu)型模式從不同的角度組合類或?qū)ο螅鼈冊诒M可能滿足各種面向?qū)ο笤O(shè)計原則的同時為類或?qū)ο蟮慕M合提供一系列巧妙的解決方案7.1結(jié)構(gòu)型模式概述7.1結(jié)構(gòu)型模式概述類結(jié)構(gòu)型模式關(guān)心類的組合,由多個類組合成一個更大的系統(tǒng),在類結(jié)構(gòu)型模式中一般只存在繼承關(guān)系和實現(xiàn)關(guān)系對象結(jié)構(gòu)型模式關(guān)心類與對象的組合,通過關(guān)聯(lián)關(guān)系,在一個類中定義另一個類的實例對象,然后通過該對象調(diào)用相應(yīng)的方法結(jié)構(gòu)型模式一覽表模式名稱定

義學習難度使用頻率適配器模式(AdapterPattern)將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。適配器模式讓那些接口不兼容的類可以一起工作?!铩铩铩铩铩飿蚪幽J?BridgePattern)將抽象部分與它的實現(xiàn)部分解耦,使得兩者都能夠獨立變化?!铩铩铩铩铩锝M合模式(CompositePattern)組合多個對象形成樹形結(jié)構(gòu),以表示具有部分-整體關(guān)系的層次結(jié)構(gòu)。組合模式讓客戶端可以統(tǒng)一對待單個對象和組合對象?!铩铩铩铩铩铩镅b飾模式(DecoratorPattern)動態(tài)地給一個對象增加一些額外的職責。就擴展功能而言,裝飾模式提供了一種比使用子類更加靈活的替代方案?!铩铩铩铩铩锿庥^模式(FacadePattern)為子系統(tǒng)中的一組接口提供一個統(tǒng)一的入口。外觀模式定義了一個高層接口,這個接口使得這一子系統(tǒng)更加容易使用?!铩铩铩铩铩锵碓J?FlyweightPattern)運用共享技術(shù)有效地支持大量細粒度對象的復用?!铩铩铩铩锎砟J?ProxyPattern)給某一個對象提供一個代理或占位符,并由代理對象來控制對原對象的訪問?!铩铩铩铩铩铩?.2

適配器模式電源適配器分析現(xiàn)實生活:不兼容:市電220V

筆記電腦20V

引入ACAdapter(交流電適配器)軟件開發(fā):存在不兼容的結(jié)構(gòu),例如方法名不一致引入適配器模式7.2

適配器模式適配器模式的定義將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。適配器模式讓那些接口不兼容的類可以一起工作。對象結(jié)構(gòu)型模式/類結(jié)構(gòu)型模式7.2.1

適配器模式的定義適配器模式的定義別名為包裝器(Wrapper)模式定義中所提及的接口是指廣義的接口,它可以表示一個方法或者方法的集合7.2.1

適配器模式的定義7.2.2適配器模式的原理與框架適配器模式的結(jié)構(gòu)(類適配器)適配器模式的結(jié)構(gòu)(對象適配器)適配器模式的三個角色Target(目標抽象類)定義把其他類轉(zhuǎn)換為何種接口,也就是我們的期望接口Adapter(適配器類)核心角色Adaptee(適配者類)源角色7.2.2適配器模式的原理與框架7.2.3應(yīng)用案例-沒有源碼的依賴庫某軟件公司曾開發(fā)了一個依賴庫,里面包含了一些常用的文件操作。例如文件讀操作和寫操作,在進行各類軟件開發(fā)時經(jīng)常需要重用該依賴庫中的算法。在為某公司開發(fā)采購管理系統(tǒng)時,開發(fā)人員發(fā)現(xiàn)需要對采購單文件進行讀寫操作;該系統(tǒng)的設(shè)計人員已經(jīng)開發(fā)了一個文件操作接口FileOperation,在該接口中聲明了基礎(chǔ)讀文件方法如read(string)和寫文件方法write(string,string)。為了增強系統(tǒng)的健壯性,開發(fā)人員決定對讀取文件的格式進行限制并添加增量寫文件方法,需要重寫依賴庫中的讀文件算法類ReadFile和寫文件算法類WriteFile,其中ReadFile的readFile(string)方法實現(xiàn)了文件讀操作,WriteFile的writeFile(string,string)方法實現(xiàn)了文件寫操作。由于某些原因,現(xiàn)在公司開發(fā)人員已經(jīng)找不到該依賴庫的源代碼,無法直接通過復制和粘貼操作來重用其中的代碼;部分開發(fā)人員已經(jīng)針對FileOperation接口編程,如果再要求對該接口進行修改或要求大家直接使用ReadFile類和WriteFile類,將導致大量代碼需要修改。軟件公司開發(fā)人員面對這個沒有源碼的依賴庫,遇到一個令人煩惱的問題:如何在既不修改現(xiàn)有接口又不需要任何算法庫代碼的基礎(chǔ)上實現(xiàn)依賴庫的重用?通過分析得知,現(xiàn)在軟件公司面對的問題有點類似最開始所提到的電壓問題,文件操作接口FileOperation好比只支持20V電壓的筆記本,而依賴庫好比220?V的家庭用電,這兩部分都沒有辦法再進行修改,而且它們原本是兩個完全不相關(guān)的結(jié)構(gòu),如圖7-2所示。7.2.3應(yīng)用案例-沒有源碼的依賴庫圖7-2需協(xié)調(diào)的兩個系統(tǒng)的結(jié)構(gòu)示意圖實例類圖圖7-3算法庫重用結(jié)構(gòu)圖7.2.3應(yīng)用案例-沒有源碼的依賴庫7.2.4適配器模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點將目標類和適配者類解耦,通過引入一個適配器類來重用現(xiàn)有的適配者類,無須修改原有結(jié)構(gòu)增加了類的透明性和復用性,提高了適配者的復用性,同一個適配者類可以在多個不同的系統(tǒng)中復用靈活性和擴展性非常好類適配器模式:置換一些適配者的方法很方便對象適配器模式:可以把多個不同的適配者適配到同一個目標,還可以適配一個適配者的子類模式缺點類適配器模式:(1)一次最多只能適配一個適配者類,不能同時適配多個適配者;(2)適配者類不能為最終類;(3)目標抽象類只能為接口,不能為類對象適配器模式:在適配器中置換適配者類的某些方法比較麻煩7.2.4適配器模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境系統(tǒng)需要使用一些現(xiàn)有的類,而這些類的接口不符合系統(tǒng)的需要,甚至沒有這些類的源代碼創(chuàng)建一個可以重復使用的類,用于和一些彼此之間沒有太大關(guān)聯(lián)的類,包括一些可能在將來引進的類一起工作7.2.4適配器模式的優(yōu)缺點與適用環(huán)境7.3橋接模式毛筆與蠟筆的“故事”12種顏色,3種型號3支毛筆+12種顏色的調(diào)色板

36支蠟筆分析蠟筆:顏色和型號兩個不同的變化維度(即兩個不同的變化原因)耦合在一起,無論是對顏色進行擴展還是對型號進行擴展都勢必會影響另一個維度毛筆:顏色和型號實現(xiàn)了分離,增加新的顏色或者型號對另一方?jīng)]有任何影響7.3橋接模式分析畫筆中存在的兩個獨立變化維度示意圖7.3橋接模式在軟件開發(fā)中如何將多個變化維度分離?7.3橋接模式橋接模式的定義對象結(jié)構(gòu)型模式橋接模式:將抽象部分與它的實現(xiàn)部分解耦,使得兩者都能夠獨立變化。7.3.1橋接模式的定義橋接模式的定義又被稱為柄體(HandleandBody)模式或接口(Interface)模式用抽象關(guān)聯(lián)取代了傳統(tǒng)的多層繼承將類之間的靜態(tài)繼承關(guān)系轉(zhuǎn)換為動態(tài)的對象組合關(guān)系7.3.1橋接模式的定義7.3.2橋接模式的原理與框架橋接模式的結(jié)構(gòu)橋接模式的結(jié)構(gòu)橋接模式包含以下4個角色:Abstraction(抽象類)RefinedAbstraction(擴充抽象類)Implementor(實現(xiàn)類接口)ConcreteImplementor(具體實現(xiàn)類)7.3.2橋接模式的原理與框架橋接模式的實現(xiàn)毛筆結(jié)構(gòu)示意圖7.3.2橋接模式的原理與框架7.3.3應(yīng)用案例-跨平臺數(shù)據(jù)處理系統(tǒng)實例說明某軟件公司欲開發(fā)一個跨平臺數(shù)據(jù)處理系統(tǒng),要求該系統(tǒng)能夠讀取TXT、JSON、XML、INI等多種格式的文件,并且能夠在Windows、Linux、Android等多個操作系統(tǒng)上運行。系統(tǒng)首先將各種格式的文件內(nèi)容解析為規(guī)定格式的數(shù)組,然后將數(shù)組內(nèi)容顯示在屏幕上,在不同的操作系統(tǒng)中可以調(diào)用不同的打印函數(shù)來顯示文件內(nèi)容。系統(tǒng)需具有較好的擴展性以支持新的文件格式和操作系統(tǒng)。試使用橋接模式設(shè)計該跨平臺圖像瀏覽系統(tǒng)。初始設(shè)計方案7.3.3應(yīng)用案例-跨平臺數(shù)據(jù)處理系統(tǒng)兩個主要問題(1)類的個數(shù)急劇增加。在各種數(shù)據(jù)的操作系統(tǒng)實現(xiàn)層提供了12個具體類,加上各級抽象層的類,系統(tǒng)中類的總個數(shù)達到了17個,在該設(shè)計方案中,具體層的類的個數(shù)=所支持的數(shù)據(jù)文件格式數(shù)×所支持的操作系統(tǒng)數(shù)。(2)系統(tǒng)擴展麻煩。由于每一個具體類既包含數(shù)據(jù)文件格式信息,又包含操作系統(tǒng)信息,因此無論是增加新的數(shù)據(jù)文件格式還是增加新的操作系統(tǒng),都需要增加大量的具體類。例如在圖7-5中增加一種新的數(shù)據(jù)文件格式Y(jié)ML,則需要增加3個具體類來實現(xiàn)該格式數(shù)據(jù)在3種不同操作系統(tǒng)的顯示;如果增加一個新的操作系統(tǒng)MacOS,為了在該操作系統(tǒng)下能夠顯示各種類型的數(shù)據(jù),需要增加4個具體類。這將導致系統(tǒng)變得非常龐大,增加運行和維護開銷。兩個獨立變化的維度數(shù)據(jù)文件格式和操作系統(tǒng)改進之后的應(yīng)用案例基本結(jié)構(gòu)說明File充當抽象類,其子類TXTFile、JSONFile、XMLFile和INIFile充當擴充抽象類;FileImp充當實現(xiàn)類接口,其子類WindowsImp、LinuxImp和AndroidImp充當具體實現(xiàn)類。如果需要更換數(shù)據(jù)文件格式或者更換操作系統(tǒng),只需修改配置文件即可,在實際使用時,可以通過分析數(shù)據(jù)文件格式后綴名來確定具體的文件格式,在程序運行時獲取操作系統(tǒng)信息來確定操作系統(tǒng)類型,無需使用配置文件。當增加新的數(shù)據(jù)文件格式或者操作系統(tǒng)時,原有系統(tǒng)無需做任何修改,只需增加一個對應(yīng)的擴充抽象類或具體實現(xiàn)類即可,系統(tǒng)具有較好的可擴展性,完全符合開閉原則。7.3.4橋接模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點分離抽象接口及其實現(xiàn)部分可以取代多層繼承方案,極大地減少了子類的個數(shù)提高了系統(tǒng)的可擴展性,在兩個變化維度中任意擴展一個維度,不需要修改原有系統(tǒng),符合開閉原則模式缺點會增加系統(tǒng)的理解與設(shè)計難度,由于關(guān)聯(lián)關(guān)系建立在抽象層,要求開發(fā)者一開始就針對抽象層進行設(shè)計與編程正確識別出系統(tǒng)中兩個獨立變化的維度并不是一件容易的事情7.3.4橋接模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境需要在抽象化和具體化之間增加更多的靈活性,避免在兩個層次之間建立靜態(tài)的繼承關(guān)系抽象部分和實現(xiàn)部分可以以繼承的方式獨立擴展而互不影響一個類存在兩個(或多個)獨立變化的維度,且這兩個(或多個)維度都需要獨立地進行擴展不希望使用繼承或因為多層繼承導致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)7.3.4橋接模式的優(yōu)缺點與適用環(huán)境7.4組合模式Windows操作系統(tǒng)目錄結(jié)構(gòu)7.4組合模式分析在樹形目錄結(jié)構(gòu)中,包含文件和文件夾兩類不同的元素在文件夾中可以包含文件,還可以繼續(xù)包含子文件夾在文件中不能再包含子文件或者子文件夾文件夾

容器(Container)文件

葉子(Leaf)7.4組合模式分析當容器對象的某一個方法被調(diào)用時,將遍歷整個樹形結(jié)構(gòu),尋找也包含這個方法的成員對象并調(diào)用執(zhí)行,牽一而動百,其中使用了遞歸調(diào)用的機制來對整個結(jié)構(gòu)進行處理由于容器對象和葉子對象在功能上的區(qū)別,在使用這些對象的代碼中必須有區(qū)別地對待容器對象和葉子對象,而實際上大多數(shù)情況下客戶端希望一致地處理它們,因為對于這些對象的區(qū)別對待將會使程序非常復雜if(is

容器對象){

//處理容器對象}elseif(is葉子對象){//處理葉子對象}7.4組合模式如何一致地對待容器對象和葉子對象?組合模式組合模式通過一種巧妙的設(shè)計方案使得用戶可以一致性地處理整個樹形結(jié)構(gòu)或者樹形結(jié)構(gòu)的一部分,它描述了如何將容器對象和葉子對象進行遞歸組合,使得用戶在使用時無須對它們進行區(qū)分,可以一致地對待容器對象和葉子對象。7.4組合模式組合模式定義對象結(jié)構(gòu)型模式組合模式:組合多個對象形成樹形結(jié)構(gòu)以表示具有部分-整體關(guān)系的層次結(jié)構(gòu)。組合模式讓客戶端可以統(tǒng)一對待單個對象和組合對象。7.4.1組合模式的定義組合模式定義又稱為“部分-整體”(Part-Whole)模式將對象組織到樹形結(jié)構(gòu)中,可以用來描述整體與部分的關(guān)系7.4.1組合模式的定義7.4.2組合模式的原理與框架組合模式的結(jié)構(gòu)組合模式的結(jié)構(gòu)組合模式包含以下3個角色:Component(抽象構(gòu)件)Leaf(葉子構(gòu)件)Composite(容器構(gòu)件)7.4.2組合模式的原理與框架7.4.3應(yīng)用案例—幾何形狀繪制軟件的框架結(jié)構(gòu)實例說明某軟件公司欲開發(fā)一個幾何形狀繪制軟件,該軟件既可以繪制組合圖形,也可以繪制基本形狀,如點、直線、曲線等。該幾何形狀繪制軟件還可以根據(jù)各類形狀的特點,為不同類型的幾何形狀提供不同的繪制方式,例如點(Dot)和直線(Line)的繪制方式就有所差異,如圖7-9所示。現(xiàn)需要提供該幾何形狀繪制軟件的整體框架設(shè)計方案。7.4.3應(yīng)用案例—幾何形狀繪制軟件的框架結(jié)構(gòu)一個組合形狀可以由基礎(chǔ)形狀結(jié)合組成,呈現(xiàn)出樹形目錄結(jié)構(gòu)7.4.3應(yīng)用案例—幾何形狀繪制軟件的框架結(jié)構(gòu)7.4.3應(yīng)用案例—幾何形狀繪制軟件的框架結(jié)構(gòu)透明組合模式與安全組合模式透明組合模式抽象構(gòu)件Component中聲明了所有用于管理成員對象的方法,包括Add()、Remove(),以及GetChild()等方法在客戶端看來,葉子對象與容器對象所提供的方法是一致的,客戶端可以一致地對待所有的對象缺點是不夠安全,因為葉子對象和容器對象在本質(zhì)上是有區(qū)別的透明組合模式與安全組合模式安全組合模式抽象構(gòu)件Component中沒有聲明任何用于管理成員對象的方法,而是在Composite類中聲明并實現(xiàn)這些方法對于葉子對象,客戶端不可能調(diào)用到這些方法缺點是不夠透明,客戶端不能完全針對抽象編程,必須有區(qū)別地對待葉子構(gòu)件和容器構(gòu)件7.4.4組合模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點可以清楚地定義分層次的復雜對象,表示對象的全部或部分層次,讓客戶端忽略了層次的差異,方便對整個層次結(jié)構(gòu)進行控制客戶端可以一致地使用一個組合結(jié)構(gòu)或其中單個對象,不必關(guān)心處理的是單個對象還是整個組合結(jié)構(gòu),簡化了客戶端代碼增加新的容器構(gòu)件和葉子構(gòu)件都很方便,符合開閉原則為樹形結(jié)構(gòu)的面向?qū)ο髮崿F(xiàn)提供了一種靈活的解決方案模式缺點在增加新構(gòu)件時很難對容器中的構(gòu)件類型進行限制7.4.4組合模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境在具有整體和部分的層次結(jié)構(gòu)中,希望通過一種方式忽略整體與部分的差異,客戶端可以一致地對待它們在一個使用面向?qū)ο笳Z言開發(fā)的系統(tǒng)中需要處理一個樹形結(jié)構(gòu)在一個系統(tǒng)中能夠分離出葉子對象和容器對象,而且它們的類型不固定,需要增加一些新的類型7.4.4組合模式的優(yōu)缺點與適用環(huán)境7.5裝飾模式現(xiàn)實生活中的“裝飾”實例裝飾模式分析可以在不改變一個對象本身功能的基礎(chǔ)上給對象增加額外的新行為是一種用于替代繼承的技術(shù),它通過一種無須定義子類的方式給對象動態(tài)增加職責,使用對象之間的關(guān)聯(lián)關(guān)系取代類之間的繼承關(guān)系引入了裝飾類,在裝飾類中既可以調(diào)用待裝飾的原有類的方法,還可以增加新的方法,以擴展原有類的功能7.5裝飾模式7.5.1裝飾模式的定義裝飾模式的定義對象結(jié)構(gòu)型模式裝飾模式:動態(tài)地給一個對象增加一些額外的職責。就擴展功能而言,裝飾模式提供了一種比使用子類更加靈活的替代方案。DecoratorPattern:Attachadditionalresponsibilitiestoanobjectdynamically.Decoratorsprovideaflexiblealternativetosubclassingforextendingfunctionality.裝飾模式的定義以對客戶透明的方式動態(tài)地給一個對象附加上更多的責任可以在不需要創(chuàng)建更多子類的情況下,讓對象的功能得以擴展7.5.1裝飾模式的定義7.5.2裝飾模式的原理與框架裝飾模式的結(jié)構(gòu)裝飾模式的結(jié)構(gòu)裝飾模式包含以下4個角色:Component(抽象構(gòu)件)ConcreteComponent(具體構(gòu)件)Decorator(抽象裝飾類)ConcreteDecorator(具體裝飾類)7.5.2裝飾模式的原理與框架7.5.3應(yīng)用案例—文件管理工具實例說明某軟件公司基于面向?qū)ο蠹夹g(shù)開發(fā)了一套文件管理工具FileManager。該工具提供了大量基本文件操作,如打開文件、讀寫文件等。由于在使用工具時,用戶經(jīng)常要求定制一些特效顯示效果,如文件壓縮、文件加密、既加密又壓縮文件等等,因此經(jīng)常需要對該工具進行擴展以增強其功能。文件管理工具功能示意圖如圖所示裝飾模式的解決方案實例類圖圖7-14文件管理工具結(jié)構(gòu)圖透明裝飾模式與半透明裝飾模式透明裝飾模式透明(Transparent)裝飾模式:要求客戶端完全針對抽象編程,裝飾模式的透明性要求客戶端程序不應(yīng)該將對象聲明為具體構(gòu)件類型或具體裝飾類型,而應(yīng)該全部聲明為抽象構(gòu)件類型對于客戶端而言,具體構(gòu)件對象和具體裝飾對象沒有任何區(qū)別透明裝飾模式與半透明裝飾模式透明裝飾模式可以讓客戶端透明地使用裝飾之前的對象和裝飾之后的對象,無須關(guān)心它們的區(qū)別可以對一個已裝飾過的對象進行多次裝飾,得到更為復雜、功能更為強大的對象無法在客戶端單獨調(diào)用新增方法AddedBehavior()……Componentcomponent_o,component_d1,component_d2;//全部使用抽象構(gòu)件定義component_o=newConcreteComponent();component_d1=newConcreteDecorator1(component_o);component_d2=newConcreteDecorator2(component_d1);component_d2.Operation();//無法單獨調(diào)用component_d2的AddedBehavior()方法……透明裝飾模式與半透明裝飾模式半透明裝飾模式半透明(Semi-transparent)裝飾模式:用具體裝飾類型來定義裝飾之后的對象,而具體構(gòu)件使用抽象構(gòu)件類型來定義對于客戶端而言,具體構(gòu)件類型無須關(guān)心,是透明的;但是具體裝飾類型必須指定,這是不透明的透明裝飾模式與半透明裝飾模式半透明裝飾模式可以給系統(tǒng)帶來更多的靈活性,設(shè)計相對簡單,使用起來也非常方便客戶端使用具體裝飾類型來定義裝飾后的對象,因此可以單獨調(diào)用AddedBehavior()方法最大的缺點在于不能實現(xiàn)對同一個對象的多次裝飾,而且客戶端需要有區(qū)別地對待裝飾之前的對象和裝飾之后的對象……Componentcomponent_o;//使用抽象構(gòu)件類型定義component_o=newConcreteComponent();component_o.Operation();ConcreteDecoratorcomponent_d;//使用具體裝飾類型定義component_d=newConcreteDecorator(component_o);component_d.Operation();component_d.AddedBehavior();//單獨調(diào)用新增業(yè)務(wù)方法……7.5.4裝飾模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點對于擴展一個對象的功能,裝飾模式比繼承更加靈活,不會導致類的個數(shù)急劇增加可以通過一種動態(tài)的方式來擴展一個對象的功能,通過配置文件可以在運行時選擇不同的具體裝飾類,從而實現(xiàn)不同的行為可以對一個對象進行多次裝飾具體構(gòu)件類與具體裝飾類可以獨立變化,用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類,且原有類庫代碼無須改變,符合開閉原則模式缺點使用裝飾模式進行系統(tǒng)設(shè)計時將產(chǎn)生很多小對象,大量小對象的產(chǎn)生勢必會占用更多的系統(tǒng)資源,在一定程度上影響程序的性能比繼承更加易于出錯,排錯也更困難,對于多次裝飾的對象,調(diào)試時尋找錯誤可能需要逐級排查,較為煩瑣7.5.4裝飾模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境在不影響其他對象的情況下,以動態(tài)、透明的方式給單個對象添加職責當不能采用繼承的方式對系統(tǒng)進行擴展或者采用繼承不利于系統(tǒng)擴展和維護時可以使用裝飾模式7.5.4裝飾模式的優(yōu)缺點與適用環(huán)境7.6外觀模式兩種喝茶方式示意圖分析一個客戶類需要和多個業(yè)務(wù)類交互,而這些需要交互的業(yè)務(wù)類經(jīng)常會作為一個整體出現(xiàn)引入一個新的外觀類(Facade)來負責和多個業(yè)務(wù)類【子系統(tǒng)(Subsystem)】進行交互,而客戶類只需與外觀類交互為多個業(yè)務(wù)類的調(diào)用提供了一個統(tǒng)一的入口,簡化了類與類之間的交互7.6外觀模式分析沒有外觀類:每個客戶類需要和多個子系統(tǒng)之間進行復雜的交互,系統(tǒng)的耦合度將很大引入外觀類:客戶類只需要直接與外觀類交互,客戶類與子系統(tǒng)之間原有的復雜引用關(guān)系由外觀類來實現(xiàn),從而降低了系統(tǒng)的耦合度7.6外觀模式分析一個子系統(tǒng)的外部與其內(nèi)部的通信通過一個統(tǒng)一的外觀類進行,外觀類將客戶類與子系統(tǒng)的內(nèi)部復雜性分隔開,使得客戶類只需要與外觀角色打交道,而不需要與子系統(tǒng)內(nèi)部的很多對象打交道7.6外觀模式7.6.1外觀模式的定義外觀模式的定義對象結(jié)構(gòu)型模式外觀模式:為子系統(tǒng)中的一組接口提供一個統(tǒng)一的入口。外觀模式定義了一個高層接口,這個接口使得這一子系統(tǒng)更加容易使用。外觀模式的定義又稱為門面模式是迪米特法則的一種具體實現(xiàn)通過引入一個新的外觀角色來降低原有系統(tǒng)的復雜度,同時降低客戶類與子系統(tǒng)的耦合度所指的子系統(tǒng)是一個廣義的概念,它可以是一個類、一個功能模塊、系統(tǒng)的一個組成部分或者一個完整的系統(tǒng)7.6.1外觀模式的定義7.6.2外觀模式的原理與框架外觀模式的結(jié)構(gòu)外觀模式的結(jié)構(gòu)外觀模式包含以下2個角色:Facade(外觀角色)SubSystem(子系統(tǒng)角色)7.6.2外觀模式的原理與框架7.6.3應(yīng)用案例——視頻解碼模塊某軟件公司欲開發(fā)一個可應(yīng)用于多個軟件的視頻解碼模塊,該模塊可以對文件中的數(shù)據(jù)進行加密,并將加密之后的數(shù)據(jù)存儲在一個新文件中。具體的流程包括三個部分,分別是讀取源文件、視頻解碼、保存解碼之后的文件,其中,讀取視頻文件和保存視頻文件使用流來實現(xiàn),解碼操作通過相應(yīng)的視頻解碼算法實現(xiàn)。這三個操作相對獨立,為了實現(xiàn)代碼的獨立重用,讓設(shè)計更符合單一職責原則,這三個操作的業(yè)務(wù)代碼封裝在三個不同的類中實例類圖圖7-17視頻解碼模塊結(jié)構(gòu)圖7.6.3應(yīng)用案例——視頻解碼模塊7.6.4外觀模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點它對客戶端屏蔽了子系統(tǒng)組件,減少了客戶端所需處理的對象數(shù)目,并使得子系統(tǒng)使用起來更加容易它實現(xiàn)了子系統(tǒng)與客戶端之間的松耦合關(guān)系,這使得子系統(tǒng)的變化不會影響到調(diào)用它的客戶端,只需要調(diào)整外觀類即可一個子系統(tǒng)的修改對其他子系統(tǒng)沒有任何影響,而且子系統(tǒng)的內(nèi)部變化也不會影響到外觀對象模式缺點不能很好地限制客戶端直接使用子系統(tǒng)類,如果對客戶端訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性如果設(shè)計不當,增加新的子系統(tǒng)可能需要修改外觀類的源代碼,違背了開閉原則7.6.4外觀模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境要為訪問一系列復雜的子系統(tǒng)提供一個簡單入口客戶端程序與多個子系統(tǒng)之間存在很大的依賴性在層次化結(jié)構(gòu)中,可以使用外觀模式的定義系統(tǒng)中每一層的入口,層與層之間不直接產(chǎn)生聯(lián)系,而是通過外觀類建立聯(lián)系,降低層之間的耦合度7.6.4外觀模式的優(yōu)缺點與適用環(huán)境7.7享元模式動機如果一個軟件系統(tǒng)在運行時所創(chuàng)建的相同或相似對象數(shù)量太多,將導致運行代價過高,帶來系統(tǒng)資源浪費、性能下降等問題如何避免系統(tǒng)中出現(xiàn)大量相同或相似的對象,同時又不影響客戶端程序通過面向?qū)ο蟮姆绞綄@些對象進行操作呢?7.7享元模式字符享元對象示意圖分析享元模式:通過共享技術(shù)實現(xiàn)相同或相似對象的重用享元池(FlyweightPool):存儲共享實例對象的地方7.7享元模式分析內(nèi)部狀態(tài)(IntrinsicState):存儲在享元對象內(nèi)部并且不會隨環(huán)境改變而改變的狀態(tài),內(nèi)部狀態(tài)可以共享(例如:字符的內(nèi)容)外部狀態(tài)(ExtrinsicState):隨環(huán)境改變而改變的、不可以共享的狀態(tài)。享元對象的外部狀態(tài)通常由客戶端保存,并在享元對象被創(chuàng)建之后,需要使用的時候再傳入到享元對象內(nèi)部。一個外部狀態(tài)與另一個外部狀態(tài)之間是相互獨立的(例如:字符的顏色和大?。?.7享元模式原理(1)將具有相同內(nèi)部狀態(tài)的對象存儲在享元池中,享元池中的對象是可以實現(xiàn)共享的(2)需要的時候?qū)ο髲南碓刂腥〕觯纯蓪崿F(xiàn)對象的復用(3)通過向取出的對象注入不同的外部狀態(tài),可以得到一系列相似的對象,而這些對象在內(nèi)存中實際上只存儲一份7.7享元模式享元模式的定義對象行為型模式享元模式:運用共享技術(shù)有效地支持大量細粒度對象的復用。FlyweightPattern:Usesharingtosupportlargenumbersoffine-grainedobjectsefficiently.7.7.1享元模式的定義享元模式的定義又稱為輕量級模式要求能夠被共享的對象必須是細粒度對象7.7.1享元模式的定義7.7.2享元模式的原理與框架享元模式的結(jié)構(gòu)享元模式的結(jié)構(gòu)享元模式包含以下4個角色:Flyweight(抽象享元類)ConcreteFlyweight(具體享元類)UnsharedConcreteFlyweight(非共享具體享元類)FlyweightFactory(享元工廠類)7.7.2享元模式的原理與框架7.7.3應(yīng)用實例實例說明某軟件公司欲開發(fā)一個飛機大戰(zhàn)游戲,其界面效果如圖7-19所示。軟件公司開發(fā)人員通過對該游戲進行分析,發(fā)現(xiàn)在飛機發(fā)射的子彈中包含大量重復單元。它們的運動方向、繪制方式都一模一樣,只是子彈的類型不同而已。如果將每一個子彈都作為一個獨立的對象存儲在內(nèi)存中,將導致該飛機大戰(zhàn)游戲在運行時所需內(nèi)存空間較大。如何降低運行代價,提高系統(tǒng)性能,是公司開發(fā)人員需要解決的一個問題。圖7-19圍棋軟件界面效果圖實例類圖圖7-20飛機大戰(zhàn)游戲重的子彈基本結(jié)構(gòu)圖7.7.3應(yīng)用實例IgoBullet充當抽象享元類BlackIgoBullet和WhiteIgoBullet充當具體享元類IgoBulletFactory充當享元工廠類7.7.3應(yīng)用實例結(jié)果及分析在實現(xiàn)享元工廠類時使用了單例模式和簡單工廠模式,確保了享元工廠對象的唯一性,并提供了工廠方法向客戶端返回享元對象7.7.3應(yīng)用實例單純享元模式和復合享元模式單純享元模式所有的具體享元類都是可以共享的,不存在非共享具體享元類復合享元模式將一些單純享元對象使用組合模式加以組合如果希望為多個內(nèi)部狀態(tài)不同的享元對象設(shè)置相同的外部狀態(tài),可以考慮使用復合享元模式單純享元模式和復合享元模式7.7.4享元模式的優(yōu)缺點與適用環(huán)境模式優(yōu)點可以減少內(nèi)存中對象的數(shù)量,使得相同或者相似的對象在內(nèi)存中只保存一份,從而可以節(jié)約系統(tǒng)資源,提高系統(tǒng)性能外部狀態(tài)相對獨立,而且不會影響其內(nèi)部狀態(tài),從而使得享元對象可以在不同的環(huán)境中被共享模式缺點使得系統(tǒng)變得復雜,需要分離出內(nèi)部狀態(tài)和外部狀態(tài),這使得程序的邏輯復雜化為了使對象可以共享,享元模式需要將享元對象的部分狀態(tài)外部化,而讀取外部狀態(tài)將使得運行時間變長7.7.4享元模式的優(yōu)缺點與適用環(huán)境模式適用環(huán)境一個系統(tǒng)有大量相同或者相似的對象,造成內(nèi)存的大量耗費對象的大部分狀態(tài)都可以外部化,可以將這些外部狀態(tài)傳入對象中在使用享元模式時需要維護一個存儲享元對象的享元池,而這需要耗費一定的系統(tǒng)資源,因此,在需要多次重復使用享元對象時才值得使用享元模式7.7.4享元模式的優(yōu)缺點與適用環(huán)境7.8代理模式商品代購示意圖分析代購商品:顧客

代購網(wǎng)站

商品軟件開發(fā):客戶端

代理對象

真實對象客戶端代理對象真實對象7.8代理模式類型遠程代理保護代理虛擬代理緩沖代理智能引用代理……7.8代理模式代理模式的定義對象結(jié)構(gòu)型模式代理模式:給某一個對象提供一個代理或占位符,并由代理對象來控制對原對象的訪問。7.8.1代理模式的定義代理模式的定義引入一個新的代理對象代理對象在客戶端對象和目標對象之間起到中介的作用去掉客戶不能看到的內(nèi)容和服務(wù)或者增添客戶需要的額外的新服務(wù)7.8.1代理模式的定義7.8.2代理模式的原理與框架代理模式的結(jié)構(gòu)代理模式的結(jié)構(gòu)代理模式包含以下3個角色:Subject(抽象主題角色)Proxy(代理主題角色)RealSubject(真實主題角色)7.8.2代理模式的原理與框架幾種常見的代理模式遠程代理(RemoteProxy):為一個位于不同的地址空間的對象提供一個本地的代理對象,這個不同的地址空間可以在同一臺主機中,也可以在另一臺主機中,遠程代理又稱為大使(Ambassador)虛擬代理(VirtualProxy):如果需要創(chuàng)建一個資源消耗較大的對象,先創(chuàng)建一個消耗相對較小的對象來表示,真實對象只在需要時才會被真正創(chuàng)建7.8.2代理模式的原理與框架幾種常見的代理模式保護代理(ProtectProxy):控制對一個對象的訪問,可以給不同的用戶提供不同級別的使用權(quán)限緩沖代理(CacheProxy):為某一個目標操作的結(jié)果提供臨時的存儲空間,以便多個客戶端可以共享這些結(jié)果智能引用代理(Smart

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論