軟件設(shè)計(jì)模式

哈爾濱華德學(xué)院第1章設(shè)計(jì)模式簡(jiǎn)介1.1什么是設(shè)計(jì)模式設(shè)計(jì)模式（pattern）是從許多優(yōu)秀的軟件系統(tǒng)中總結(jié)出的成功的可復(fù)用的設(shè)計(jì)方案。每一個(gè)設(shè)計(jì)模式描述一個(gè)在我們周?chē)粩嘀貜?fù)發(fā)生的問(wèn)題，以及該問(wèn)題的解決方案的核心。設(shè)計(jì)模式是對(duì)被用來(lái)在特定場(chǎng)景下解決一般設(shè)計(jì)問(wèn)題的類和相互通信的對(duì)象的描述。模式體現(xiàn)的是程序整體的構(gòu)思，所以有時(shí)候它也會(huì)出現(xiàn)在分析或者是概要設(shè)計(jì)階段模式的核心思想是通過(guò)增加抽象層，把變化部分從那些不變部分里分離出來(lái)軟件工程專業(yè)2023/2/131.1什么是設(shè)計(jì)模式設(shè)計(jì)模式的四要素模式名稱(PatternName)問(wèn)題(Problem)解決方案(Solution)效果(consequences)軟件工程專業(yè)2023/2/141.2設(shè)計(jì)模式的起源軟件領(lǐng)域的設(shè)計(jì)模式起源于建筑學(xué)。

1977年，建筑大師Alexander出版了《APatternLanguage：Towns,Building,Construction》一書(shū)。受Alexander著作的影響，KentBeck和WardCunningham在1987年舉行的一次面向?qū)ο蟮臅?huì)議上發(fā)表了論文：《在面向?qū)ο缶幊讨惺褂媚Ｊ健贰?023/2/1軟件工程專業(yè)51.2設(shè)計(jì)模式的起源

目前，被公認(rèn)在設(shè)計(jì)模式領(lǐng)域最具影響力的著作是ErichGamma、RichardHelm、RalphJohnson和JohnVlissides在1994年合作出版的著作：《DesignPatterns：ElementsofReusableObject-OrientedSoftware》（中譯本《設(shè)計(jì)模式：可復(fù)用的面向?qū)ο筌浖幕驹怼坊颉对O(shè)計(jì)模式》），該書(shū)被廣大喜愛(ài)者昵稱為GOF（GangofFour）之書(shū)，被認(rèn)為是學(xué)習(xí)設(shè)計(jì)模式的必讀著作，GOF之書(shū)已經(jīng)被公認(rèn)為是設(shè)計(jì)模式領(lǐng)域的奠基之作。2023/2/1軟件工程專業(yè)61.3設(shè)計(jì)模式的分類設(shè)計(jì)模式分為三種類型，共23種。創(chuàng)建型模式：?jiǎn)卫Ｊ?、抽象工廠模式、建造者模式、工廠模式、原型模式。結(jié)構(gòu)型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態(tài)模式、策略模式、職責(zé)鏈模式、訪問(wèn)者模式。2023/2/1軟件工程專業(yè)71.4什么是框架框架通常定義了應(yīng)用體系的整體結(jié)構(gòu)類和對(duì)象的關(guān)系等等設(shè)計(jì)參數(shù)，以便于具體應(yīng)用實(shí)現(xiàn)者能集中精力于應(yīng)用本身的特定細(xì)節(jié)?？蚣苤饕涗涇浖?yīng)用中共同的設(shè)計(jì)決策，框架強(qiáng)調(diào)設(shè)計(jì)復(fù)用，因此框架設(shè)計(jì)中必然要使用設(shè)計(jì)模式設(shè)計(jì)模式有助于對(duì)框架結(jié)構(gòu)的理解，成熟的框架通常使用了多種設(shè)計(jì)模式,如果你熟悉這些設(shè)計(jì)模式2023/2/1軟件工程專業(yè)8第2章面向?qū)ο蟮膸讉€(gè)基本原則2.1面向抽象原則設(shè)計(jì)一個(gè)類時(shí)，不讓該類面向具體的類，而是面向抽象類或接口。包含抽象方法的類稱為抽象類，在面向?qū)ο蟮某绦蛟O(shè)計(jì)思想中，抽象類只能做為父類使用，不能被實(shí)例化為對(duì)象。Java里面由于不允許多重繼承，所以如果要實(shí)現(xiàn)多個(gè)類的功能，則可以通過(guò)實(shí)現(xiàn)多個(gè)接口來(lái)實(shí)現(xiàn)。2023/2/1軟件工程專業(yè)102.2開(kāi)-閉原則設(shè)計(jì)應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。模塊應(yīng)盡量在不修改原代碼的情況下進(jìn)行擴(kuò)展?？梢栽谲浖瓿珊髮?duì)軟件進(jìn)行擴(kuò)展，加入新的功能。這樣，軟件就可通過(guò)不斷的增加新模塊滿足不斷變化的新需求。由于不修改軟件原來(lái)的模塊，不用擔(dān)心軟件的穩(wěn)定性。2023/2/1軟件工程專業(yè)112.3里氏代換原則如果調(diào)用的是父類的話，那么換成子類也完全可以運(yùn)行。2023/2/1軟件工程專業(yè)122.4依賴倒轉(zhuǎn)原則抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依賴于抽象。要針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程。2023/2/1軟件工程專業(yè)132.5多用組合少用繼承原則設(shè)計(jì)中避開(kāi)類繼承的缺點(diǎn)，充分使用對(duì)象組合的優(yōu)點(diǎn)。2023/2/1軟件工程專業(yè)142.6高內(nèi)聚-低耦合原則如果類中的方法是一組相關(guān)的行為，則稱該類是高內(nèi)聚的，反之稱為低內(nèi)聚的。所謂低耦合就是盡量不要讓一個(gè)類含有太多的其它類的實(shí)例的引用，以避免修改系統(tǒng)的其中一部分會(huì)影響到其它部分。2023/2/1軟件工程專業(yè)15第3章UML類圖簡(jiǎn)介3.1類(Class)在UML中，使用一個(gè)長(zhǎng)方形描述一個(gè)類的主要構(gòu)成，將長(zhǎng)方形垂直地分為三層。第1層是名字層，類名字是常規(guī)字形，表明該類是具體類，類名字是斜體字形，表明該類是抽象類。第2層是變量層，也稱屬性層，列出類的成員變量及類型，格式是“變量名字：類型”。第3層是方法層，也稱操作層，列出類的方法及返回類型，格式是“方法名字（參數(shù)列表）：類型”2023/2/1軟件工程專業(yè)173.1類(Class)2023/2/1軟件工程專業(yè)18Student+name:String#age:int-money:double+setName(String):void#printMess():void+getAge():intsetAge(int):void-getMoney();名字層

變量層

方法層

+#--protected的private的友好的的public的變量或方法的訪問(wèn)權(quán)限是名字前加3.2接口（Interface）表示接口的UML圖和表示類的UML圖類似，使用一個(gè)長(zhǎng)方形描述一個(gè)接口的主要構(gòu)成，將長(zhǎng)方形垂直地分為三層。第1層是名字層，接口的名字必須是斜體字形，而且需要用<<interface>>修飾名字，并且該修飾和名字分列在2行。第2層是常量層，列出接口中的常量及類型，格式是“常量名字：類型”。第3層是方法層，也稱操作層，列出接口中的方法及返回類型，格式是“方法名字（參數(shù)列表）：類型”。2023/2/1軟件工程專業(yè)193.2接口（Interface）2023/2/1軟件工程專業(yè)20<<interface>>Creator

+MAX:int+factoryMethod():Product名字層

常量層

方法層

+public的常量或方法的訪問(wèn)權(quán)限是名字前加3.3泛化關(guān)系（Generalization）2023/2/1軟件工程專業(yè)21

對(duì)于面向?qū)ο笳Z(yǔ)言，UML中所說(shuō)的泛化關(guān)系就是指類的繼承關(guān)系。如果一個(gè)類是另一個(gè)類的子類，那么UML通過(guò)使用一個(gè)實(shí)線連接兩個(gè)類的UML圖來(lái)表示二者之間的繼承關(guān)系，實(shí)線的起始端是子類的UML圖，終點(diǎn)端是父類的UML圖，但終點(diǎn)端使用一個(gè)空心的三角形表示實(shí)線的結(jié)束。3.4關(guān)聯(lián)關(guān)系2023/2/1軟件工程專業(yè)22

如果A類中成員變量是用B類（接口）來(lái)聲明的變量，那么A和B的關(guān)系是關(guān)聯(lián)關(guān)系，稱A關(guān)聯(lián)于B。那么UML通過(guò)使用一個(gè)實(shí)線連A和B的UML圖，實(shí)線的起始端是A的UML圖，終點(diǎn)端是B的UML圖，但終點(diǎn)端使用一個(gè)指向B的UML圖的方向箭頭表示實(shí)線的結(jié)束。3.5依賴關(guān)系2023/2/1軟件工程專業(yè)23

如果A類中某個(gè)方法的參數(shù)用B類（接口）來(lái)聲明的變量或某個(gè)方法返回的數(shù)據(jù)類型是B類型的，那么A和B的關(guān)系是依賴關(guān)系，稱A依賴于B。那么UML通過(guò)使用一個(gè)虛線連A和B的UML圖，虛線的起始端是A的UML圖，終點(diǎn)端是B的UML圖，但終點(diǎn)端使用一個(gè)指向B的UML圖的方向箭頭表示虛線的結(jié)束。3.6實(shí)現(xiàn)關(guān)系2023/2/1軟件工程專業(yè)24

如果一個(gè)類實(shí)現(xiàn)了一個(gè)接口，那么類和接口的關(guān)系是實(shí)現(xiàn)關(guān)系，稱類實(shí)現(xiàn)接口。UML通過(guò)使用虛線連接類和它所實(shí)現(xiàn)的接口，虛線起始端是類，虛線的終點(diǎn)端是它實(shí)現(xiàn)的接口，但終點(diǎn)端使用一個(gè)空心的三角形表示虛線的結(jié)束。3.7注釋2023/2/1軟件工程專業(yè)25UML使用注釋為類圖提供附加的說(shuō)明。UML在一個(gè)帶卷角的長(zhǎng)方形中顯示給出的注釋，并使用虛線將這個(gè)帶卷角的長(zhǎng)方形和所它所注釋的實(shí)體連接起來(lái)。第4章工廠模式4.1工廠模式問(wèn)題在面向?qū)ο缶幊讨?最通常的方法是一個(gè)new操作符產(chǎn)生一個(gè)對(duì)象實(shí)例,new操作符就是用來(lái)構(gòu)造對(duì)象實(shí)例的。一些情況下,new操作符直接生成對(duì)象會(huì)帶來(lái)一些問(wèn)題。創(chuàng)建對(duì)象之前必須清楚所要?jiǎng)?chuàng)建對(duì)象的類信息，但個(gè)別情況下無(wú)法達(dá)到此要求。許多類型對(duì)象的創(chuàng)造需要一系列步驟。在這些情況,新對(duì)象的建立就是一個(gè)“過(guò)程”，而不僅僅是一個(gè)操作。2023/2/1軟件工程專業(yè)274.1工廠模式問(wèn)題2023/2/1軟件工程專業(yè)28模式的問(wèn)題：你如何能輕松方便地構(gòu)造對(duì)象實(shí)例，而不必關(guān)心構(gòu)造對(duì)象實(shí)例的細(xì)節(jié)和復(fù)雜過(guò)程呢？4.2工廠模式的解決方案舉個(gè)例子假如還沒(méi)有工業(yè)革命，如果一個(gè)客戶要一款寶馬車(chē),一般的做法是客戶去生產(chǎn)一款寶馬車(chē)，然后拿來(lái)用。后來(lái)出現(xiàn)工業(yè)革命。用戶不用去創(chuàng)建寶馬車(chē)。因?yàn)榭蛻粲幸粋€(gè)工廠來(lái)幫他創(chuàng)建寶馬.想要什么車(chē)，這個(gè)工廠就可以建。

2023/2/1軟件工程專業(yè)294.2工廠模式的解決方案舉個(gè)例子（續(xù)）為了滿足客戶，寶馬車(chē)系列越來(lái)越多，如320i，523i,30li等系列一個(gè)工廠無(wú)法創(chuàng)建所有的寶馬系列。于是由單獨(dú)分出來(lái)多個(gè)具體的工廠。每個(gè)具體工廠創(chuàng)建一種系列。隨著客戶的要求越來(lái)越高，寶馬車(chē)必須配置空調(diào)。而且這空調(diào)必須對(duì)應(yīng)給系列車(chē)才能使用。于是這個(gè)工廠開(kāi)始生產(chǎn)寶馬車(chē)和需要的空調(diào)。最終是客戶只要對(duì)寶馬的銷(xiāo)售員說(shuō)：我要523i空調(diào)車(chē)，銷(xiāo)售員就直接給他523i空調(diào)車(chē)了。而不用自己去創(chuàng)建523i空調(diào)車(chē)寶馬車(chē).

2023/2/1軟件工程專業(yè)304.2工廠模式的解決方案結(jié)論產(chǎn)品應(yīng)該由工廠生產(chǎn)，而不是由客戶去生產(chǎn)?？蛻糁恍枰喇a(chǎn)品在哪買(mǎi)，而不需要知道產(chǎn)品如何制作。類的對(duì)象也是一種產(chǎn)品，所以需要對(duì)象工廠去負(fù)責(zé)創(chuàng)建。解決方案：建立一個(gè)工廠來(lái)創(chuàng)建對(duì)象。2023/2/1軟件工程專業(yè)314.3工廠模式的分類在GOF的《設(shè)計(jì)模式》一書(shū)中，工廠模式就是說(shuō)明通過(guò)工廠類來(lái)創(chuàng)建對(duì)象的模式。工廠模式分為三類：簡(jiǎn)單工廠模式工廠方法模式抽象工廠模式這三種模式從上到下逐步抽象，并且更具一般性。GOF在《設(shè)計(jì)模式》一書(shū)中將工廠模式分為兩類：工廠方法模式（FactoryMethod）與抽象工廠模式（AbstractFactory）。將簡(jiǎn)單工廠模式（SimpleFactory）看為工廠方法模式的一種特例，兩者歸為一類。

2023/2/1軟件工程專業(yè)324.3工廠模式的分類簡(jiǎn)單工廠模式由一個(gè)工廠對(duì)象決定創(chuàng)建出哪一種產(chǎn)品類的實(shí)例工廠模式家族中最簡(jiǎn)單實(shí)用的模式，可以理解為是不同工廠模式的一個(gè)特殊實(shí)現(xiàn)。是由一個(gè)工廠類根據(jù)傳入的參數(shù)，動(dòng)態(tài)決定應(yīng)該創(chuàng)建哪一個(gè)產(chǎn)品類（這些產(chǎn)品類繼承自一個(gè)父類或接口）的實(shí)例。2023/2/1軟件工程專業(yè)334.3工廠模式的分類簡(jiǎn)單工廠模式（續(xù)）該模式中包含的角色及其職責(zé)工廠（Creator）角色抽象產(chǎn)品（Product）角色具體產(chǎn)品（ConcreteProduct）角色2023/2/1軟件工程專業(yè)344.3工廠模式的分類簡(jiǎn)單工廠模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)354.3工廠模式的分類工廠方法模式定義一個(gè)創(chuàng)建產(chǎn)品對(duì)象的工廠接口，將實(shí)際創(chuàng)建工作推遲到子類當(dāng)中。核心工廠類不再負(fù)責(zé)產(chǎn)品的創(chuàng)建，這樣核心類成為一個(gè)抽象工廠角色，僅負(fù)責(zé)具體工廠子類必須實(shí)現(xiàn)的接口。工廠方法模式是簡(jiǎn)單工廠模式的衍生，解決了許多簡(jiǎn)單工廠模式的問(wèn)題。首先完全實(shí)現(xiàn)‘開(kāi)－閉原則’，實(shí)現(xiàn)了可擴(kuò)展。2023/2/1軟件工程專業(yè)364.3工廠模式的分類工廠方法模式（續(xù)）該模式中包含的角色及其職責(zé)抽象工廠(Creator)角色具體工廠(ConcreteCreator)角色抽象產(chǎn)品(Product)角色具體產(chǎn)品(ConcreteProduct)角色2023/2/1軟件工程專業(yè)374.3工廠模式的分類工廠方法模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)384.3工廠模式的分類抽象工廠模式所有形態(tài)的工廠模式中最為抽象和最具一般性的一種形態(tài)。抽象工廠模式是指當(dāng)有多個(gè)抽象角色時(shí)，使用的一種工廠模式。抽象工廠模式可以向客戶端提供一個(gè)接口，使客戶端在不必指定產(chǎn)品的具體的情況下，創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象。為創(chuàng)建一組相關(guān)或相互依賴的對(duì)象提供一個(gè)接口，而且無(wú)需指定他們的具體類。2023/2/1軟件工程專業(yè)394.3工廠模式的分類抽象工廠模式（續(xù)）抽象工廠模式的用意為：給客戶端提供一個(gè)接口，可以創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象，而且使用抽象工廠模式還要滿足一下條件：系統(tǒng)中有多個(gè)產(chǎn)品族，而系統(tǒng)一次只可能消費(fèi)其中一族產(chǎn)品。同屬于同一個(gè)產(chǎn)品族的產(chǎn)品以其使用。2023/2/1軟件工程專業(yè)404.3工廠模式的分類抽象工廠模式（續(xù)）該模式中包含的角色及其職責(zé)抽象工廠(Creator)角色具體工廠(ConcreteCreator)角色抽象產(chǎn)品(Product)角色具體產(chǎn)品(ConcreteProduct)角色2023/2/1軟件工程專業(yè)414.3工廠模式的分類抽象工廠模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)42第5章單例模式5.1單例模式問(wèn)題幾乎所有面向?qū)ο蟮某绦蛑?，總有一些類的?duì)象需要是唯一的。例如，通過(guò)數(shù)據(jù)庫(kù)句柄到數(shù)據(jù)庫(kù)的連接是獨(dú)占的。2023/2/1軟件工程專業(yè)44模式問(wèn)題：怎樣確保一個(gè)特殊類的實(shí)例是獨(dú)一無(wú)二的（它是這個(gè)類的唯一實(shí)例），并且這個(gè)實(shí)例易于被訪問(wèn)呢？5.2單例模式的解決方案舉個(gè)例子有一個(gè)成語(yǔ)叫“獨(dú)一無(wú)二”，以表示事物的珍貴在中國(guó)古代，就有“國(guó)無(wú)二主”的說(shuō)法，也就是說(shuō)一個(gè)國(guó)家只有一個(gè)皇帝。2023/2/1軟件工程專業(yè)455.2單例模式的解決方案一個(gè)全局變量使得一個(gè)對(duì)象可以被訪問(wèn)，但它不能防止你實(shí)例化多個(gè)對(duì)象。因?yàn)槟愕娜魏未a都能修改全局變量，這將不可避免的引起更多調(diào)試的意外。換句話說(shuō)，全局變量的狀態(tài)總是會(huì)出現(xiàn)一些問(wèn)題的。讓類自身負(fù)責(zé)保存它的唯一實(shí)例(靜態(tài)變量)。這個(gè)類可以保證沒(méi)有其他實(shí)例可以被創(chuàng)建（通過(guò)截取創(chuàng)建新對(duì)象的請(qǐng)求），并且它可以提供一個(gè)訪問(wèn)該實(shí)例的方法（靜態(tài)方法）。2023/2/1軟件工程專業(yè)465.2單例模式的解決方案

單例模式定義：“一個(gè)類有且僅有一個(gè)實(shí)例，并且自行實(shí)例化向整個(gè)系統(tǒng)提供?！?023/2/1軟件工程專業(yè)475.3單例模式結(jié)構(gòu)模式的結(jié)構(gòu)中只包括一個(gè)角色單件類（Singleton）單例模式有兩種形式餓漢單例,也就是,類被加載的時(shí)候就已經(jīng)創(chuàng)建好了單例。懶漢單例,也就是第一次調(diào)用的時(shí)候被創(chuàng)建。2023/2/1軟件工程專業(yè)485.3單例模式結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)49第6章原型模式6.1原型模式問(wèn)題在軟件系統(tǒng)中，客戶希望創(chuàng)建一個(gè)類對(duì)象（產(chǎn)品）時(shí)，可能有三種情況：知道產(chǎn)品具體型號(hào)(使用new運(yùn)算符創(chuàng)建)不知道型號(hào)，知道特定的需求(使用工廠模式)不知道需求，但想要一個(gè)。和已知對(duì)象相同的對(duì)象。2023/2/1軟件工程專業(yè)516.1原型模式問(wèn)題模式問(wèn)題：當(dāng)對(duì)象的構(gòu)造函數(shù)非常復(fù)雜，在生成新對(duì)象的時(shí)候非常耗時(shí)間、耗資源的情況？我們是怎么來(lái)創(chuàng)建呢？2023/2/1軟件工程專業(yè)526.1原型模式解決方案舉個(gè)例子：例子1：孫悟空拔下一嘬猴毛，輕輕一吹就會(huì)變出好多的孫悟空來(lái)。例子2：寄個(gè)快遞下面是一個(gè)郵寄快遞的場(chǎng)景：“給我寄個(gè)快遞。”顧客說(shuō)?！凹耐裁吹胤?？寄給……？”你問(wèn)?！昂蜕洗尾畈欢嘁粯樱皇青]寄給另外一個(gè)地址，這里是郵寄地址……”顧客一邊說(shuō)一邊把寫(xiě)有郵寄地址的紙條給你。“好！”你愉快地答應(yīng)，因?yàn)槟惚４媪擞脩舻囊郧班]寄信息，只要復(fù)制這些數(shù)據(jù)，然后通過(guò)簡(jiǎn)單的修改就可以快速地創(chuàng)建新的快遞數(shù)據(jù)了。

2023/2/1軟件工程專業(yè)536.2原型模式解決方案通過(guò)復(fù)制（克隆、拷貝）一個(gè)指定類型的對(duì)象來(lái)創(chuàng)建更多同類型的對(duì)象。這個(gè)指定的對(duì)象可被稱為“原型”對(duì)象，也就是通過(guò)復(fù)制原型對(duì)象來(lái)得到更多同類型的對(duì)象。用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過(guò)拷貝這些原型創(chuàng)建新的對(duì)象的模式稱為原型模式。原型模式是從一個(gè)對(duì)象出發(fā)得到一個(gè)和自己有相同狀態(tài)的新對(duì)象的成熟模式，該模式的關(guān)鍵是將一個(gè)對(duì)象定義為原型，并為其提供復(fù)制自己的方法。2023/2/1軟件工程專業(yè)546.2原型模式解決方案2023/2/1軟件工程專業(yè)556.2原型模式解決方案淺拷貝指被拷貝對(duì)象的所有變量都含有與原對(duì)象相同的值，而且對(duì)其他對(duì)象的引用仍然是指向原來(lái)的對(duì)象。即淺拷貝只負(fù)責(zé)當(dāng)前對(duì)象實(shí)例，對(duì)引用的對(duì)象不做拷貝。2023/2/1軟件工程專業(yè)566.2原型模式解決方案深拷貝指被拷貝對(duì)象的所有的變量都含有與原來(lái)對(duì)象相同的值，除了那些引用其他對(duì)象的變量。那些引用其他對(duì)象的變量將指向一個(gè)被拷貝的新對(duì)象，而不再是原有那些被引用對(duì)象。即深拷貝把要拷貝的對(duì)象所引用的對(duì)象也都拷貝了一次，而這種對(duì)被引用到的對(duì)象拷貝叫做間接拷貝。2023/2/1軟件工程專業(yè)576.3原型模式的結(jié)構(gòu)模式的結(jié)構(gòu)中包括兩種角色：抽象原型（Prototype）具體原型（ConcretePrototype）2023/2/1軟件工程專業(yè)586.3原型模式的結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)59第7章外觀模式7.1外觀模式問(wèn)題我們通過(guò)外觀的包裝，使應(yīng)用程序只能看到外觀對(duì)象，而不會(huì)看到具體的細(xì)節(jié)對(duì)象，這樣無(wú)疑會(huì)降低應(yīng)用程序的復(fù)雜度，并且提高了程序的可維護(hù)性。2023/2/1軟件工程專業(yè)61模式問(wèn)題：為了降低復(fù)雜性，常常將系統(tǒng)劃分為若干個(gè)子系統(tǒng)。但是如何做到各個(gè)系統(tǒng)之間的通信和相互依賴關(guān)系達(dá)到最小呢？7.2模式的解決方案舉個(gè)例子一個(gè)電源總開(kāi)關(guān)可以控制四盞燈、一個(gè)風(fēng)扇、一臺(tái)空調(diào)和一臺(tái)電視機(jī)的啟動(dòng)和關(guān)閉。該電源總開(kāi)關(guān)可以同時(shí)控制上述所有電器設(shè)備。2023/2/1軟件工程專業(yè)627.2模式的解決方案2023/2/1軟件工程專業(yè)637.2模式的解決方案2023/2/1軟件工程專業(yè)647.2模式的解決方案外觀模式為系統(tǒng)中的一組接口提供一個(gè)一致的界面，F(xiàn)a?ade模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。外觀模式的關(guān)鍵是為子系統(tǒng)提供一個(gè)稱作外觀的類，該外觀類的實(shí)例負(fù)責(zé)和子系統(tǒng)中類的實(shí)例打交道當(dāng)用戶想要和子系統(tǒng)中的若干個(gè)類的實(shí)例打交道時(shí)，可以代替地和子系統(tǒng)的外觀類的實(shí)例打交道。2023/2/1軟件工程專業(yè)657.3外觀模式的結(jié)構(gòu)模式的結(jié)構(gòu)中包括兩種角色子系統(tǒng)（Subsystem）外觀（Facade）2023/2/1軟件工程專業(yè)667.3外觀模式的結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)67第8章裝飾模式8.1裝飾模式的問(wèn)題若你從事過(guò)面向?qū)ο箝_(kāi)發(fā)，實(shí)現(xiàn)給一個(gè)類或?qū)ο笤黾有袨?，使用繼承機(jī)制，這是所有面向?qū)ο笳Z(yǔ)言的一個(gè)基本特性。如果已經(jīng)存在的一個(gè)類缺少某些方法，或者須要給方法添加更多的功能（魅力），你也許會(huì)僅僅繼承這個(gè)類來(lái)產(chǎn)生一個(gè)新類—這建立在額外的代碼上。通過(guò)繼承一個(gè)現(xiàn)有類可以使得子類在擁有自身方法的同時(shí)還擁有父類的方法。但是這種方法是靜態(tài)的，用戶不能控制增加行為的方式和時(shí)機(jī)。2023/2/1軟件工程專業(yè)698.1裝飾模式的問(wèn)題模式問(wèn)題：你如何組織你的代碼使其可以容易的添加基本的或者一些很少用到的特性，而不是直接將額外的代碼寫(xiě)在你的類的內(nèi)部？2023/2/1軟件工程專業(yè)708.2裝飾模式的解決方案舉個(gè)例子一個(gè)鳥(niǎo)只能飛100米，如果讓它飛行150米，就必須給它裝一個(gè)電子翅膀，就可以實(shí)現(xiàn)飛行更遠(yuǎn)的距離。2023/2/1軟件工程專業(yè)718.2裝飾模式的解決方案裝飾模式是在不必改變?cè)愇募褪褂美^承的情況下，動(dòng)態(tài)地?cái)U(kuò)展一個(gè)對(duì)象的功能。它是通過(guò)創(chuàng)建一個(gè)包裝對(duì)象，也就是裝飾來(lái)包裹真實(shí)的對(duì)象。裝飾模式動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)或者行為。就增加功能來(lái)說(shuō)，裝飾模式相比生成子類更為靈活。裝飾器模式提供了改變子類的靈活方案。裝飾器模式在不必改變?cè)愇募褪褂美^承的情況下，動(dòng)態(tài)的擴(kuò)展一個(gè)對(duì)象的功能。它是通過(guò)創(chuàng)建一個(gè)包裝對(duì)象，也就是裝飾來(lái)包裹真實(shí)的對(duì)象。2023/2/1軟件工程專業(yè)728.3裝飾模式的結(jié)構(gòu)裝飾模式的結(jié)構(gòu)中包括四種角色：抽象組件（Component）具體組件（ConcreteComponent）裝飾（Decorator）具體裝飾（ConcreteDecotator）2023/2/1軟件工程專業(yè)738.3裝飾模式的結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)74第9章橋接模式9.1橋接模式的問(wèn)題在軟件系統(tǒng)中，某些類型由于自身的邏輯，它具有兩個(gè)或多個(gè)維度的變化，那么如何應(yīng)對(duì)這種“多維度的變化”？如何利用面向?qū)ο蟮募夹g(shù)來(lái)使得該類型能夠輕松的沿著多個(gè)方向進(jìn)行變化，而又不引入額外的復(fù)雜度？2023/2/1軟件工程專業(yè)769.2橋接模式的解決方案舉個(gè)例子例子1：設(shè)想如果要繪制矩形、圓形、橢圓、正方形，我們至少需要4個(gè)形狀類，但是如果繪制的圖形需要具有不同的顏色，如紅色、綠色、藍(lán)色等，此時(shí)至少有如下兩種設(shè)計(jì)方案：?第一種設(shè)計(jì)方案是為每一種形狀都提供一套各種顏色的版本。?第二種設(shè)計(jì)方案是根據(jù)實(shí)際需要對(duì)形狀和顏色進(jìn)行組合。2023/2/1軟件工程專業(yè)779.2橋接模式的解決方案橋接模式將抽象部分與它的實(shí)現(xiàn)部分分離，使得它們都可以獨(dú)立地變化。將抽象化與實(shí)現(xiàn)化脫耦，使得二者可以獨(dú)立地變化抽象化就是忽略一些信息，把不同的實(shí)體當(dāng)作同樣的實(shí)體對(duì)待。在面向?qū)ο笾?，將?duì)象的共同性質(zhì)抽取出來(lái)形成類的過(guò)程即為抽象化的過(guò)程。針對(duì)抽象化給出的具體實(shí)現(xiàn)，就是實(shí)現(xiàn)化，抽象化與實(shí)現(xiàn)化是一對(duì)互逆的概念，實(shí)現(xiàn)化產(chǎn)生的對(duì)象比抽象化更具體，是對(duì)抽象化事物的進(jìn)一步具體化的產(chǎn)物2023/2/1軟件工程專業(yè)789.2橋接模式的解決方案將抽象化與實(shí)現(xiàn)化脫耦，使得二者可以獨(dú)立地變化脫耦就是將抽象化和實(shí)現(xiàn)化之間的耦合解脫開(kāi)，或者說(shuō)是將它們之間的強(qiáng)關(guān)聯(lián)改換成弱關(guān)聯(lián)，將兩個(gè)角色之間的繼承關(guān)系改為關(guān)聯(lián)關(guān)系。橋接模式中的所謂脫耦，就是指在一個(gè)軟件系統(tǒng)的抽象化和實(shí)現(xiàn)化之間使用關(guān)聯(lián)關(guān)系（組合或者聚合關(guān)系）而不是繼承關(guān)系，從而使兩者可以相對(duì)獨(dú)立地變化，這就是橋接模式的用意。2023/2/1軟件工程專業(yè)799.3橋接模式的結(jié)構(gòu)模式的結(jié)構(gòu)中包括四種角色抽象（Abstraction）實(shí)現(xiàn)者（Implementor）細(xì)化抽象（RefinedAbstraction）具體實(shí)現(xiàn)者（ConcreteImplementor）2023/2/1軟件工程專業(yè)809.3橋接模式的結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)81第10章命令模式10.1命令模式的問(wèn)題在軟件設(shè)計(jì)中，我們經(jīng)常需要向某些對(duì)象發(fā)送請(qǐng)求，但是并不知道請(qǐng)求的接收者是誰(shuí)，也不知道被請(qǐng)求的操作是哪個(gè)。我們只需在程序運(yùn)行時(shí)指定具體的請(qǐng)求接收者即可在軟件系統(tǒng)中，“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。在這種情況下，如何將“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”解耦？2023/2/1軟件工程專業(yè)8310.2命令模式的解決方案舉個(gè)例子電視機(jī)遙控器:遙控器是請(qǐng)求的發(fā)送者，電視機(jī)是請(qǐng)求的接收者，遙控器上有一些按鈕如開(kāi)，關(guān),換頻道等按鈕就是具體命令，不同的按鈕對(duì)應(yīng)電視機(jī)的不同操作。2023/2/1軟件工程專業(yè)8410.2命令模式的解決方案命令模式(CommandPattern)：將將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使我們可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及支持可撤銷(xiāo)的操作。2023/2/1軟件工程專業(yè)8510.3命令模式的結(jié)構(gòu)模式的結(jié)構(gòu)中包括四種角色：接收者（Receiver）命令(Command)接口具體命令（ConcreteCommand）請(qǐng)求者（Invoker）2023/2/1軟件工程專業(yè)8610.3命令模式的結(jié)構(gòu)UML類圖2023/2/1軟件工程專業(yè)87第11章觀察者模式11.1觀察者模式的問(wèn)題一些面向?qū)ο蟮木幊谭绞剑峁┝艘环N構(gòu)建對(duì)象間復(fù)雜網(wǎng)絡(luò)互連的能力。當(dāng)對(duì)象們連接在一起時(shí)，它們就可以相互提供服務(wù)和信息。通常來(lái)說(shuō)，當(dāng)某個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，你仍然需要對(duì)象之間能互相通信。當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，你如何通知其他對(duì)象？是否需要一個(gè)動(dòng)態(tài)方案――一個(gè)就像允許腳本的執(zhí)行一樣，允許自由連接的方案？2023/2/1軟件工程專業(yè)8911.2觀察者模式的解決方案舉個(gè)例子用戶界面可以作為一個(gè)觀察者，業(yè)務(wù)數(shù)據(jù)是被觀察者，用戶界面觀察業(yè)務(wù)數(shù)據(jù)的變化，發(fā)現(xiàn)數(shù)據(jù)變化后，就顯示在界面上。2023/2/1軟件工程專業(yè)9011.2觀察者模式的解決方案定義對(duì)象間的一種一對(duì)多的依賴關(guān)系,當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí),所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。觀察者模式允許一個(gè)對(duì)象關(guān)注其他對(duì)象的狀態(tài)，并且，觀察者模式還為被觀測(cè)者提供了一種觀測(cè)結(jié)構(gòu)，或者說(shuō)是一個(gè)主體和一個(gè)客體。主體，也就是被觀測(cè)者，可以用來(lái)聯(lián)系所有的觀測(cè)它的觀測(cè)者?？腕w，也就是觀測(cè)者，用來(lái)接受主體狀態(tài)的改變觀測(cè)就是一個(gè)