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

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

1977年，建筑大師Alexander出版了《APatternLanguage：Towns,Building,Construction》一書。受Alexander著作的影響，KentBeck和WardCunningham在1987年舉行的一次面向?qū)ο蟮臅h上發(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ì)模式》），該書被廣大喜愛者昵稱為GOF（GangofFour）之書，被認(rèn)為是學(xué)習(xí)設(shè)計(jì)模式的必讀著作，GOF之書已經(jīng)被公認(rèn)為是設(shè)計(jì)模式領(lǐng)域的奠基之作。2023/2/1軟件工程專業(yè)61.3設(shè)計(jì)模式的分類設(shè)計(jì)模式分為三種類型，共23種。創(chuàng)建型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。結(jié)構(gòu)型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態(tài)模式、策略模式、職責(zé)鏈模式、訪問者模式。2023/2/1軟件工程專業(yè)71.4什么是框架框架通常定義了應(yīng)用體系的整體結(jié)構(gòu)類和對象的關(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ì)模式有助于對框架結(jié)構(gòu)的理解，成熟的框架通常使用了多種設(shè)計(jì)模式,如果你熟悉這些設(shè)計(jì)模式2023/2/1軟件工程專業(yè)8第2章面向?qū)ο蟮膸讉€基本原則2.1面向抽象原則設(shè)計(jì)一個類時，不讓該類面向具體的類，而是面向抽象類或接口。包含抽象方法的類稱為抽象類，在面向?qū)ο蟮某绦蛟O(shè)計(jì)思想中，抽象類只能做為父類使用，不能被實(shí)例化為對象。Java里面由于不允許多重繼承，所以如果要實(shí)現(xiàn)多個類的功能，則可以通過實(shí)現(xiàn)多個接口來實(shí)現(xiàn)。2023/2/1軟件工程專業(yè)102.2開-閉原則設(shè)計(jì)應(yīng)當(dāng)對擴(kuò)展開放，對修改關(guān)閉。模塊應(yīng)盡量在不修改原代碼的情況下進(jìn)行擴(kuò)展?？梢栽谲浖瓿珊髮浖M(jìn)行擴(kuò)展，加入新的功能。這樣，軟件就可通過不斷的增加新模塊滿足不斷變化的新需求。由于不修改軟件原來的模塊，不用擔(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)依賴于抽象。要針對接口編程，而不是針對實(shí)現(xiàn)編程。2023/2/1軟件工程專業(yè)132.5多用組合少用繼承原則設(shè)計(jì)中避開類繼承的缺點(diǎn)，充分使用對象組合的優(yōu)點(diǎn)。2023/2/1軟件工程專業(yè)142.6高內(nèi)聚-低耦合原則如果類中的方法是一組相關(guān)的行為，則稱該類是高內(nèi)聚的，反之稱為低內(nèi)聚的。所謂低耦合就是盡量不要讓一個類含有太多的其它類的實(shí)例的引用，以避免修改系統(tǒng)的其中一部分會影響到其它部分。2023/2/1軟件工程專業(yè)15第3章UML類圖簡介3.1類(Class)在UML中，使用一個長方形描述一個類的主要構(gòu)成，將長方形垂直地分為三層。第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的變量或方法的訪問權(quán)限是名字前加3.2接口（Interface）表示接口的UML圖和表示類的UML圖類似，使用一個長方形描述一個接口的主要構(gòu)成，將長方形垂直地分為三層。第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的常量或方法的訪問權(quán)限是名字前加3.3泛化關(guān)系（Generalization）2023/2/1軟件工程專業(yè)21

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

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

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

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

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

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

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

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

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