常用軟件設(shè)計模式

軟件設(shè)計模式與體系結(jié)構(gòu)推薦書籍面向?qū)ο笤O(shè)計原則概述面向?qū)ο笤O(shè)計原則簡介常用的面向?qū)ο笤O(shè)計原則包括7個，這些原則并不是孤立存在的，它們相互依賴，相互補充。設(shè)計原則名稱設(shè)計原則簡介重要性單一職責(zé)原則(SingleResponsibilityPrinciple,SRP)類的職責(zé)要單一，不能將太多的職責(zé)放在一個類中★★★★☆開閉原則(Open-ClosedPrinciple,OCP)軟件實體對擴展是開放的，但對修改是關(guān)閉的，即在不修改一個軟件實體的基礎(chǔ)上去擴展其功能★★★★★里氏代換原則(LiskovSubstitutionPrinciple,LSP)在軟件系統(tǒng)中，一個可以接受基類對象的地方必然可以接受一個子類對象★★★★☆依賴倒轉(zhuǎn)原則(DependencyInversionPrinciple,DIP)要針對抽象層編程，而不要針對具體類編程★★★★★接口隔離原則(InterfaceSegregationPrinciple,ISP)使用多個專門的接口來取代一個統(tǒng)一的接口★★☆☆☆合成復(fù)用原則(CompositeReusePrinciple,CRP)在系統(tǒng)中應(yīng)該盡量多使用組合和聚合關(guān)聯(lián)關(guān)系，盡量少使用甚至不使用繼承關(guān)系★★★★☆迪米特法則(LawofDemeter,LoD)一個軟件實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通信，那么這兩個類就不應(yīng)當(dāng)發(fā)生直接的相互作用，而是通過引入一個第三者發(fā)生間接交互★★★☆☆單一職責(zé)原則單一職責(zé)原則定義單一職責(zé)原則(SingleResponsibilityPrinciple,SRP)定義如下：一個對象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個類中。其英文定義為：Everyobjectshouldhaveasingleresponsibility,andthatresponsibilityshouldbeentirelyencapsulatedbytheclass.另一種定義方式如下：就一個類而言，應(yīng)該僅有一個引起它變化的原因。其英文定義為：Thereshouldneverbemorethanonereasonforaclasstochange.在Form1中寫了很多功能？單一職責(zé)原則單一職責(zé)原則分析一個類（或者大到模塊，小到方法）承擔(dān)的職責(zé)越多，它被復(fù)用的可能性越小，而且如果一個類承擔(dān)的職責(zé)過多，就相當(dāng)于將這些職責(zé)耦合在一起，當(dāng)其中一個職責(zé)變化時，可能會影響其他職責(zé)的運作。類的職責(zé)主要包括兩個方面：數(shù)據(jù)職責(zé)和行為職責(zé)，數(shù)據(jù)職責(zé)通過其屬性來體現(xiàn)，而行為職責(zé)通過其方法來體現(xiàn)。單一職責(zé)原則是實現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針，在很多代碼重構(gòu)手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設(shè)計人員發(fā)現(xiàn)類的不同職責(zé)并將其分離，而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計人員具有較強的分析設(shè)計能力和相關(guān)重構(gòu)經(jīng)驗。單一職責(zé)原則單一職責(zé)原則實例實例說明某基于Java的C/S系統(tǒng)的“登錄功能”通過如下登錄類(Login)實現(xiàn)：現(xiàn)使用單一職責(zé)原則對其進行重構(gòu)。單一職責(zé)原則單一職責(zé)原則實例實例解析開閉原則開閉原則定義開閉原則(Open-ClosedPrinciple,OCP)定義如下：一個軟件實體應(yīng)當(dāng)對擴展開放，對修改關(guān)閉。也就是說在設(shè)計一個模塊的時候，應(yīng)當(dāng)使這個模塊可以在不被修改的前提下被擴展，即實現(xiàn)在不修改源代碼的情況下改變這個模塊的行為。其英文定義為：Softwareentitiesshouldbeopenforextension,butclosedformodification.開閉原則開閉原則分析開閉原則由BertrandMeyer于1988年提出，它是面向?qū)ο笤O(shè)計中最重要的原則之一。在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結(jié)構(gòu)或一個獨立的類。開閉原則開閉原則分析抽象化是開閉原則的關(guān)鍵。開閉原則還可以通過一個更加具體的“對可變性封裝原則”來描述，對可變性封裝原則(PrincipleofEncapsulationofVariation,EVP)要求找到系統(tǒng)的可變因素并將其封裝起來。

需求不斷變化，使系統(tǒng)在不斷變化中保持穩(wěn)定，多擴展，少修改。利用抽象，隔離變化。面向?qū)ο蟮暮诵膶㈩l繁變化的部分抽象拒絕不成熟的抽象開閉原則開閉原則實例實例說明某圖形界面系統(tǒng)提供了各種不同形狀的按鈕，客戶端代碼可針對這些按鈕進行編程，用戶可能會改變需求要求使用不同的按鈕，原始設(shè)計方案如圖所示：現(xiàn)對該系統(tǒng)進行重構(gòu)，使之滿足開閉原則的要求。變化開閉原則開閉原則實例實例解析很多軟件設(shè)計模式，就是為了更好的體現(xiàn)（實現(xiàn)）開閉原則。依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則定義依賴倒轉(zhuǎn)原則(DependenceInversionPrinciple,DIP)的定義如下：高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象。其英文定義為：Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,detailsshoulddependuponabstractions.另一種表述為：要針對接口編程，不要針對實現(xiàn)編程。其英文定義為：Programtoaninterface,notanimplementation.電腦中各個配件的關(guān)系？依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則分析簡單來說，依賴倒轉(zhuǎn)原則就是指：代碼要依賴于抽象的類，而不要依賴于具體的類；要針對接口或抽象類編程，而不是針對具體類編程。實現(xiàn)開閉原則的關(guān)鍵是抽象化，并且從抽象化導(dǎo)出具體化實現(xiàn)，如果說開閉原則是面向?qū)ο笤O(shè)計的目標(biāo)的話，那么依賴倒轉(zhuǎn)原則就是面向?qū)ο笤O(shè)計的主要手段。所有依賴關(guān)系，均應(yīng)終止于抽象類或者接口依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則實例：數(shù)據(jù)庫訪問：高層模塊調(diào)用低層程序包

（高層依賴于低層）每次更換不同數(shù)據(jù)庫時，高層模塊也要做出更改

（不能復(fù)用高層模塊）但高層模塊的業(yè)務(wù)邏輯卻改變不大。依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則分析（如何實現(xiàn)依賴倒轉(zhuǎn)？）類之間的耦合零耦合關(guān)系具體耦合關(guān)系抽象耦合關(guān)系依賴倒轉(zhuǎn)原則要求客戶端依賴于抽象耦合，以抽象方式耦合是依賴倒轉(zhuǎn)原則的關(guān)鍵。里氏代換原則里氏代換原則里氏代換原則定義更容易理解的定義方式：所有引用基類（父類）的地方必須能透明地使用其子類的對象?；蛘撸喊阉械母割?，全部替換為子類，則軟件行為沒有變化其英文定義為：Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswithoutknowingit.只有子類可替換掉父類，父類才可真正被復(fù)用依賴倒置原則的根本里氏代換原則里氏代換原則分析里氏代換原則是實現(xiàn)開閉原則的重要方式之一。由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型

來對對象進行定義。而在運行時再確定其子類類型，用子類對象

來替換父類對象。子類可替換性，使得使用父類的模塊，不修改實現(xiàn)擴展。（引用不同的子類對象）依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則分析依賴注入構(gòu)造注入(ConstructorInjection)：通過構(gòu)造函數(shù)注入實例變量。設(shè)值注入(SetterInjection)：通過Setter方法注入實例變量。接口注入(InterfaceInjection)：通過接口方法注入實例變量。

依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則實例實例說明某系統(tǒng)提供一個數(shù)據(jù)轉(zhuǎn)換模塊，可以將來自不同數(shù)據(jù)源的數(shù)據(jù)轉(zhuǎn)換成多種格式，如可以轉(zhuǎn)換來自數(shù)據(jù)庫的數(shù)據(jù)(DatabaseSource)、也可以轉(zhuǎn)換來自文本文件的數(shù)據(jù)(TextSource)，轉(zhuǎn)換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則實例實例說明由于需求的變化，該系統(tǒng)可能需要增加新的數(shù)據(jù)源或者新的文件格式，每增加一個新的類型的數(shù)據(jù)源或者新的類型的文件格式，客戶類MainClass都需要修改源代碼，以便使用新的類，但違背了開閉原則?，F(xiàn)使用依賴倒轉(zhuǎn)原則對其進行重構(gòu)。依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則實例實例解析設(shè)計模式的誕生與發(fā)展模式的誕生與定義模式起源于建筑業(yè)而非軟件業(yè)模式(Pattern)之父——美國加利佛尼亞大學(xué)環(huán)境結(jié)構(gòu)中心研究所所長ChristopherAlexander博士《APatternLanguage:Towns,Buildings,Construction》——253個建筑和城市規(guī)劃模式模式Context（模式可適用的前提條件）Theme或Problem（在特定條件下要解決的目標(biāo)問題）Solution（對目標(biāo)問題求解過程中各種物理關(guān)系的記述）設(shè)計模式的誕生與發(fā)展模式的誕生與定義Alexander給出了關(guān)于模式的經(jīng)典定義：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心，通過這種方式，我們可以無數(shù)次地重用那些已有的解決方案，無需再重復(fù)相同的工作。Apatternisasolutiontoaprobleminacontext

模式是在特定環(huán)境中解決問題的一種方案設(shè)計模式的誕生與發(fā)展軟件模式1990年，軟件工程界開始關(guān)注ChristopherAlexander等在這一住宅、公共建筑與城市規(guī)劃領(lǐng)域的重大突破，最早將該模式的思想引入軟件工程方法學(xué)的是1991-1992年以“四人組(GangofFour，GoF，分別是ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)”自稱的四位著名軟件工程學(xué)者，他們在1994年歸納發(fā)表了23種在軟件開發(fā)中使用頻率較高的設(shè)計模式，旨在用模式來統(tǒng)一溝通面向?qū)ο蠓椒ㄔ诜治?、設(shè)計和實現(xiàn)間的鴻溝。設(shè)計模式的誕生與發(fā)展軟件模式軟件模式是將模式的一般概念應(yīng)用于軟件開發(fā)領(lǐng)域，即軟件開發(fā)的總體指導(dǎo)思路或參照樣板。軟件模式并非僅限于設(shè)計模式，還包括架構(gòu)模式、分析模式和過程模式等，實際上，在軟件生存期的每一個階段都存在著一些被認同的模式。軟件模式可以認為是對軟件開發(fā)這一特定“問題”的“解法”的某種統(tǒng)一表示，它和Alexander所描述的模式定義完全相同，即軟件模式等于一定條件下的出現(xiàn)的問題以及解法。軟件模式的基礎(chǔ)結(jié)構(gòu)由4個部分構(gòu)成：問題描述、前提條件（環(huán)境或約束條件）、解法和效果。設(shè)計模式的定義與分類設(shè)計模式的定義設(shè)計模式(DesignPattern)是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計經(jīng)驗的總結(jié)，使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設(shè)計模式的定義與分類設(shè)計模式的基本要素設(shè)計模式一般有如下幾個基本要素：模式名稱、問題、目的、解決方案、效果、實例代碼和相關(guān)設(shè)計模式，其中的關(guān)鍵元素包括以下四個方面：模式名稱(Patternname)問題(Problem)解決方案(Solution)效果(Consequences)設(shè)計模式的定義與分類設(shè)計模式學(xué)習(xí)步驟本書將按照以下次序來學(xué)習(xí)設(shè)計模式：模式動機與定義模式結(jié)構(gòu)與分析模式實例與解析模式效果與應(yīng)用模式擴展設(shè)計模式的定義與分類設(shè)計模式的分類根據(jù)其目的（模式是用來做什么的）可分為創(chuàng)建型(Creational)，結(jié)構(gòu)型(Structural)和行為型(Behavioral)三種：創(chuàng)建型模式主要用于創(chuàng)建對象。結(jié)構(gòu)型模式主要用于處理類或?qū)ο蟮慕M合。行為型模式主要用于描述對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)。GoF設(shè)計模式簡介范圍\目的創(chuàng)建型模式結(jié)構(gòu)型模式行為型模式類模式工廠方法模式（類）適配器模式解釋器模式模板方法模式對象模式抽象工廠模式建造者模式原型模式單例模式（對象）適配器模式橋接模式組合模式裝飾模式外觀模式享元模式代理模式職責(zé)鏈模式命令模式迭代器模式中介者模式備忘錄模式觀察者模式狀態(tài)模式策略模式訪問者模式創(chuàng)建型模式創(chuàng)建型模式概述創(chuàng)建型模式(CreationalPattern)對類的實例化過程進行了抽象，能夠?qū)④浖K中對象的創(chuàng)建和對象的使用分離。為了使軟件的結(jié)構(gòu)更加清晰，外界對于這些對象只需要知道它們共同的接口，而不清楚其具體的實現(xiàn)細節(jié)，使整個系統(tǒng)的設(shè)計更加符合單一職責(zé)原則。創(chuàng)建型模式創(chuàng)建型模式概述創(chuàng)建型模式在創(chuàng)建什么(What)，由誰創(chuàng)建(Who)，何時創(chuàng)建(When)等方面都為軟件設(shè)計者提供了盡可能大的靈活性。創(chuàng)建型模式隱藏了類的實例的創(chuàng)建細節(jié)，通過隱藏對象如何被創(chuàng)建和組合在一起達到使整個系統(tǒng)獨立的目的。創(chuàng)建型模式簡單工廠模式（SimpleFactory）

工廠方法模式（FactoryMethod）抽象工廠模式（AbstractFactory）建造者模式（Builder）原型模式（Prototype）單例模式（Singleton）創(chuàng)建型模式簡介簡單工廠模式模式動機只需要知道水果的名字則可得到相應(yīng)的水果簡單工廠模式模式動機考慮一個簡單的軟件應(yīng)用場景，一個軟件系統(tǒng)可以提供多個外觀不同的按鈕（如圓形按鈕、矩形按鈕、菱形按鈕等），這些按鈕都源自同一個基類，不過在繼承基類后不同的子類修改了部分屬性從而使得它們可以呈現(xiàn)不同的外觀我們希望在使用這些按鈕時，不需要知道這些具體按鈕類的名字，只需要知道表示該按鈕類的一個參數(shù)，并提供一個調(diào)用方便的方法，把該參數(shù)傳入方法即可返回一個相應(yīng)的按鈕對象，此時，就可以使用簡單工廠模式。簡單工廠模式模式定義簡單工廠模式(SimpleFactoryPattern)：又稱為靜態(tài)工廠方法(StaticFactoryMethod)模式，它屬于類創(chuàng)建型模式。在簡單工廠模式中，可以根據(jù)參數(shù)的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責(zé)創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類?？捎酶割愐弥赶?qū)ο蠛唵喂S模式模式結(jié)構(gòu)接口或抽象父類簡單工廠模式模式分析分析如下代碼：publicvoidpay(Stringtype){if(type.equalsIgnoreCase("cash")){//創(chuàng)建先進支付的對象

//現(xiàn)金支付處理代碼}elseif(type.equalsIgnoreCase("creditcard")){//信用卡支付處理代碼（生成對象）}elseif(type.equalsIgnoreCase("voucher")){//代金券支付處理代碼（生成對象）}else{……}}代碼復(fù)雜，難以維護簡單工廠模式模式分析重構(gòu)后的代碼：publicabstractclassAbstractPay{publicabstractvoidpay();}publicclassCashPayextendsAbstractPay{publicvoidpay(){//現(xiàn)金支付處理代碼}}抽象支付類具體支付類簡單工廠模式模式分析重構(gòu)后的代碼：publicclassPayMethodFactory{publicstaticAbstractPay

getPayMethod(Stringtype){if(type.equalsIgnoreCase("cash")){returnnewCashPay();//根據(jù)參數(shù)創(chuàng)建具體產(chǎn)品}elseif(type.equalsIgnoreCase("creditcard")){returnnewCreditcardPay();//根據(jù)參數(shù)創(chuàng)建具體產(chǎn)品}……}}支付工廠簡單工廠模式模式實例與解析實例一：簡單電視機工廠某電視機廠專為各知名電視機品牌代工生產(chǎn)各類電視機，當(dāng)需要海爾牌電視機時只需要在調(diào)用該工廠的工廠方法時傳入?yún)?shù)“Haier”，需要海信電視機時只需要傳入?yún)?shù)“Hisense”，工廠可以根據(jù)傳入的不同參數(shù)返回不同品牌的電視機?，F(xiàn)使用簡單工廠模式來模擬該電視機工廠的生產(chǎn)過程。簡單工廠模式模式實例與解析實例一：簡單電視機工廠簡單工廠模式模式優(yōu)缺點簡單工廠模式的優(yōu)點工廠類含有必要的判斷邏輯，可以決定在什么時候創(chuàng)建哪一個產(chǎn)品類的實例，客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責(zé)任，而僅僅“消費”產(chǎn)品；簡單工廠模式通過這種做法實現(xiàn)了對責(zé)任的分割?？蛻舳藷o須知道所創(chuàng)建的具體產(chǎn)品類的類名，只需要知道具體產(chǎn)品類所對應(yīng)的參數(shù)即可，對于一些復(fù)雜的類名，通過簡單工廠模式可以減少使用者的記憶量。通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產(chǎn)品類，在一定程度上提高了系統(tǒng)的靈活性。簡單工廠模式模式優(yōu)缺點簡單工廠模式的缺點由于工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，一旦不能正常工作，整個系統(tǒng)都要受到影響。使用簡單工廠模式將會增加系統(tǒng)中類的個數(shù)，在一定程序上增加了系統(tǒng)的復(fù)雜度和理解難度。系統(tǒng)擴展困難，一旦添加新產(chǎn)品就不得不修改工廠邏輯，在產(chǎn)品類型較多時，有可能造成工廠邏輯過于復(fù)雜，不利于系統(tǒng)的擴展和維護。簡單工廠模式由于使用了靜態(tài)工廠方法，造成工廠角色無法形成基于繼承的等級結(jié)構(gòu)。簡單工廠模式模式適用環(huán)境在以下情況下可以使用簡單工廠模式：工廠類負責(zé)創(chuàng)建的對象比較少：由于創(chuàng)建的對象較少，不會造成工廠方法中的業(yè)務(wù)邏輯太過復(fù)雜?？蛻舳酥恢纻魅牍S類的參數(shù)，對于如何創(chuàng)建對象不關(guān)心：客戶端既不需要關(guān)心創(chuàng)建細節(jié)，甚至連類名都不需要記住，只需要知道類型所對應(yīng)的參數(shù)。簡單工廠模式模式擴展簡單工廠模式的簡化：在有些情況下工廠類可以由抽象產(chǎn)品角色扮演，一個抽象產(chǎn)品類同時也是子類的工廠，也就是說把靜態(tài)工廠方法寫到抽象產(chǎn)品類中。工廠方法模式簡單工廠模式的不足在簡單工廠模式中，只提供了一個工廠類，該工廠類處于對產(chǎn)品類進行實例化的中心位置，它知道每一個產(chǎn)品對象的創(chuàng)建細節(jié)，并決定何時實例化哪一個產(chǎn)品類。簡單工廠模式最大的缺點是當(dāng)有新產(chǎn)品要加入到系統(tǒng)中時，必須修改工廠類，加入必要的處理邏輯，這違背了“開閉原則”。在簡單工廠模式中，所有的產(chǎn)品都是由同一個工廠創(chuàng)建，工廠類職責(zé)較重，業(yè)務(wù)邏輯較為復(fù)雜，具體產(chǎn)品與工廠類之間的耦合度高，嚴(yán)重影響了系統(tǒng)的靈活性和擴展性，而工廠方法模式則可以很好地解決這一問題。工廠方法模式工廠方法模式模式定義工廠方法模式(FactoryMethodPattern)又稱為工廠模式，也叫虛擬構(gòu)造器(VirtualConstructor)模式或者多態(tài)工廠(PolymorphicFactory)模式，它屬于類創(chuàng)建型模式。在工廠方法模式中，工廠父類負責(zé)定義創(chuàng)建產(chǎn)品對象的公共接口，而工廠子類則負責(zé)生成具體的產(chǎn)品對象，這樣做的目的是將產(chǎn)品類的實例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應(yīng)該實例化哪一個具體產(chǎn)品類。工廠方法模式模式結(jié)構(gòu)工廠方法模式模式分析工廠方法模式是簡單工廠模式的進一步抽象和推廣。由于使用了面向?qū)ο蟮亩鄳B(tài)性，工廠方法模式保持了簡單工廠模式的優(yōu)點，而且克服了它的缺點。在工廠方法模式中，核心的工廠類不再負責(zé)所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建工作交給子類去做。這個核心類僅僅負責(zé)給出具體工廠必須實現(xiàn)的接口，而不負責(zé)哪一個產(chǎn)品類被實例化這種細節(jié)，這使得工廠方法模式可以允許系統(tǒng)在不修改工廠角色的情況下引進新產(chǎn)品。

工廠方法模式模式分析當(dāng)系統(tǒng)擴展需要添加新的產(chǎn)品對象時，僅僅需要添加一個具體產(chǎn)品對象以及一個具體工廠對象，原有工廠對象不需要進行任何修改，也不需要修改客戶端，很好地符合了“開閉原則”。而簡單工廠模式在添加新產(chǎn)品對象后不得不修改工廠方法，擴展性不好。工廠方法模式退化后可以演變成簡單工廠模式。工廠方法模式模式實例與解析實例一：電視機工廠將原有的工廠進行分割，為每種品牌的電視機提供一個子工廠，海爾工廠專門負責(zé)生產(chǎn)海爾電視機，海信工廠專門負責(zé)生產(chǎn)海信電視機，如果需要生產(chǎn)TCL電視機或創(chuàng)維電視機，只需要對應(yīng)增加一個新的TCL工廠或創(chuàng)維工廠即可，原有的工廠無須做任何修改，使得整個系統(tǒng)具有更加的靈活性和可擴展性。工廠方法模式工廠方法模式模式優(yōu)缺點工廠方法模式的優(yōu)點在工廠方法模式中，工廠方法用來創(chuàng)建客戶所需要的產(chǎn)品，同時還向客戶隱藏了哪種具體產(chǎn)品類將被實例化這一細節(jié)，用戶只需要關(guān)心所需產(chǎn)品對應(yīng)的工廠，無須關(guān)心創(chuàng)建細節(jié)，甚至無須知道具體產(chǎn)品類的類名。基于工廠角色和產(chǎn)品角色的多態(tài)性設(shè)計是工廠方法模式的關(guān)鍵。它能夠使工廠可以自主確定創(chuàng)建何種產(chǎn)品對象，而如何創(chuàng)建這個對象的細節(jié)則完全封裝在具體工廠內(nèi)部。工廠方法模式之所以又被稱為多態(tài)工廠模式，是因為所有的具體工廠類都具有同一抽象父類。使用工廠方法模式的另一個優(yōu)點是在系統(tǒng)中加入新產(chǎn)品時，無須修改抽象工廠和抽象產(chǎn)品提供的接口，也無須修改其他的具體工廠和具體產(chǎn)品，而只要添加一個具體工廠和具體產(chǎn)品就可以了。并根據(jù)客戶端調(diào)用需求，調(diào)用相關(guān)的工廠即可，這樣，系統(tǒng)的可擴展性也就變得非常好，完全符合“開閉原則”。建造者模式(生成器模式)建造者模式模式動機無論是在現(xiàn)實世界中還是在軟件系統(tǒng)中，都存在一些復(fù)雜的對象，它們擁有多個組成部分，如汽車，它包括車輪、方向盤、發(fā)送機等各種部件。而對于大多數(shù)用戶而言，無須知道這些部件的裝配細節(jié)，也幾乎不會使用單獨某個部件，而是使用一輛完整的汽車，可以通過建造者模式對其進行設(shè)計與描述。建造者模式可以將部件和其組裝過程分開，一步一步創(chuàng)建一個復(fù)雜的對象。用戶只需要指定復(fù)雜對象的類型就可以得到該對象，而無須知道其內(nèi)部的具體構(gòu)造細節(jié)。建造者模式模式動機建造者模式模式動機在軟件開發(fā)中，也存在大量類似汽車一樣的復(fù)雜對象，它們擁有一系列成員屬性，這些成員屬性中有些是引用類型的成員對象。而且在這些復(fù)雜對象中，還可能存在一些限制條件，如某些屬性沒有賦值則復(fù)雜對象不能作為一個完整的產(chǎn)品使用；有些屬性的賦值必須按照某個順序，一個屬性沒有賦值之前，另一個屬性可能無法賦值等。復(fù)雜對象相當(dāng)于一輛有待建造的汽車，而對象的屬性相當(dāng)于汽車的部件，建造產(chǎn)品的過程就相當(dāng)于組合部件的過程。由于組合部件的過程很復(fù)雜，因此，這些部件的組合過程往往被“外部化”到一個稱作建造者的對象里，建造者返還給客戶端的是一個已經(jīng)建造完畢的完整產(chǎn)品對象，而用戶無須關(guān)心該對象所包含的屬性以及它們的組裝方式，這就是建造者模式的模式動機。建造者模式模式定義建造者模式(BuilderPattern)：將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。建造者模式是一步一步創(chuàng)建一個復(fù)雜的對象，它允許用戶只通過指定復(fù)雜對象的類型和內(nèi)容就可以構(gòu)建它們，用戶不需要知道內(nèi)部的具體構(gòu)建細節(jié)。建造者模式屬于對象創(chuàng)建型模式。根據(jù)中文翻譯的不同，建造者模式又可以稱為生成器模式。建造者模式模式分析一個典型的復(fù)雜對象其類代碼示例如下：publicclassProduct{ privateStringpartA;//可以是任意類型

privateStringpartB; privateStringpartC; //partA的Getter方法和Setter方法省略

//partB的Getter方法和Setter方法省略

//partC的Getter方法和Setter方法省略…………

其他成員的代碼等……}建造者模式模式結(jié)構(gòu)抽象建造者具體建造者（多個）建造者模式模式結(jié)構(gòu)建造者模式包含如下角色：Builder：抽象建造者ConcreteBuilder：具體建造者Director：指揮者Product：產(chǎn)品角色建造者模式模式分析抽象建造者類中定義了產(chǎn)品的創(chuàng)建方法和返回方法，其典型代碼如下：publicabstractclassBuilder{ protectedProductproduct=newProduct();

publicabstractvoidbuildPartA(); publicabstractvoidbuildPartB(); publicabstractvoidbuildPartC();

publicProductgetResult() { returnproduct; }}抽象建造方法建造者模式模式分析建造者模式的結(jié)構(gòu)中還引入了一個指揮者類Director，該類的作用主要有兩個：一方面它隔離了客戶與生產(chǎn)過程；另一方面它負責(zé)控制產(chǎn)品的生成過程。指揮者針對抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過指揮者類調(diào)用建造者的相關(guān)方法，返回一個完整的產(chǎn)品對象。

建造者模式模式分析指揮者類的代碼示例如下：publicclassDirector{ privateBuilderbuilder;

publicDirector(Builderbuilder) { this.builder=builder; }

publicvoidsetBuilder(Builderbuilder) { this.builder=builer; }

publicProductconstruct() { builder.buildPartA(); builder.buildPartB(); builder.buildPartC(); returnbuilder.getResult(); }}設(shè)置建造類型建造并返回建造者模式模式分析客戶端類代碼片段：在客戶端代碼中，無須關(guān)心產(chǎn)品對象的具體組裝過程，只需確定具體建造者的類型即可，建造者模式將復(fù)雜對象的構(gòu)建與對象的表現(xiàn)分離開來，這樣使得同樣的構(gòu)建過程可以創(chuàng)建出不同的表現(xiàn)?！瑽uilderbuilder=newConcreteBuilder();Directordirector=newDirector(builder);Productproduct=director.construct();……選擇建造類型建造并返回建造者模式建造者模式實例與解析實例：KFC套餐建造者模式可以用于描述KFC如何創(chuàng)建套餐：套餐是一個復(fù)雜對象，它一般包含主食（如漢堡、雞肉卷等）和飲料（如果汁、可樂等）等組成部分，不同的套餐有不同的組成部分，而KFC的服務(wù)員可以根據(jù)顧客的要求，一步一步裝配這些組成部分，構(gòu)造一份完整的套餐，然后返回給顧客。建造者模式建造者模式實例與解析KFC使用了建造者模式建造者模式建造者模式實例與解析實例：KFC套餐套餐A套餐B建造者模式模式優(yōu)缺點建造者模式的優(yōu)點在建造者模式中，客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié)，將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過程解耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象。每一個具體建造者都相對獨立，而與其他的具體建造者無關(guān)，因此可以很方便地替換具體建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產(chǎn)品對象。可以更加精細地控制產(chǎn)品的創(chuàng)建過程。將復(fù)雜產(chǎn)品的創(chuàng)建步驟分解在不同的方法中，使得創(chuàng)建過程更加清晰，也更方便使用程序來控制創(chuàng)建過程。增加新的具體建造者無須修改原有類庫的代碼，指揮者類針對抽象建造者類編程，系統(tǒng)擴展方便，符合“開閉原則”。建造者模式模式優(yōu)缺點建造者模式的缺點如下：建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點，其組成部分相似，如果產(chǎn)品之間的差異性很大（抽象建造者），則不適合使用建造者模式，因此其使用范圍受到一定的限制。如果產(chǎn)品的內(nèi)部變化復(fù)雜，可能會導(dǎo)致需要定義很多具體建造者類來實現(xiàn)這種變化，導(dǎo)致系統(tǒng)變得很龐大。建造者模式模式適用環(huán)境在以下情況下可以使用建造者模式：需要生成的產(chǎn)品對象有復(fù)雜的內(nèi)部結(jié)構(gòu)，這些產(chǎn)品對象通常包含多個成員屬性。需要生成的產(chǎn)品對象的屬性相互依賴，需要指定其生成順序。對象的創(chuàng)建過程獨立于創(chuàng)建該對象的類。在建造者模式中引入了指揮者類，將創(chuàng)建過程封裝在指揮者類中，而不在建造者類中。隔離復(fù)雜對象的創(chuàng)建和使用，并使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品。建造者模式模式比較建造者模式與抽象工廠模式的比較與抽象工廠模式相比，建造者模式返回一個組裝好的完整產(chǎn)品，而抽象工廠模式返回一系列相關(guān)的產(chǎn)品，這些產(chǎn)品位于不同的產(chǎn)品等級結(jié)構(gòu)，構(gòu)成了一個產(chǎn)品族。在抽象工廠模式中，客戶端實例化工廠類，然后調(diào)用工廠方法獲取所需產(chǎn)品對象，而在建造者模式中，客戶端可以不直接調(diào)用建造者的相關(guān)方法，而是通過指揮者類來指導(dǎo)如何生成對象，包括對象的組裝過程和建造步驟，它側(cè)重于一步步構(gòu)造一個復(fù)雜對象，返回一個完整的對象。如果將抽象工廠模式看成汽車配件生產(chǎn)工廠，生產(chǎn)一個產(chǎn)品族的產(chǎn)品，那么建造者模式就是一個汽車組裝工廠，通過對部件的組裝可以返回一輛完整的汽車。單例模式單例模式模式動機對于系統(tǒng)中的某些類來說，只有一個實例很重要，例如，一個系統(tǒng)中可以存在多個打印任務(wù)，但是只能有一個正在工作的任務(wù)；一個系統(tǒng)只能有一個窗口管理器或文件系統(tǒng)；一個系統(tǒng)只能有一個計時工具或ID（序號）生成器。單例模式模式動機如何保證一個類只有一個實例并且這個實例易于被訪問呢？定義一個全局變量可以確保對象隨時都可以被訪問，但不能防止我們實例化多個對象。一個更好的解決辦法是讓類自身負責(zé)保存它的唯一實例。這個類可以保證沒有其他實例被創(chuàng)建，并且它可以提供一個訪問該實例的方法。這就是單例模式的模式動機。單例模式模式定義單例模式(SingletonPattern)：單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例，這個類稱為單例類，它提供全局訪問的方法。單例模式的要點有三個：一是某個類只能有一個實例；二是它必須自行創(chuàng)建這個實例；三是它必須自行向整個系統(tǒng)提供這個實例。單例模式是一種對象創(chuàng)建型模式。單例模式又名單件模式或單態(tài)模式。單例模式模式結(jié)構(gòu)單例模式模式分析單例模式的目的是保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。單例模式包含的角色只有一個，就是單例類——Singleton。單例類擁有一個私有構(gòu)造函數(shù)，確保用戶無法通過new關(guān)鍵字直接實例化它。除此之外，該模式中包含一個靜態(tài)私有成員變量與靜態(tài)公有的工廠方法，該工廠方法負責(zé)檢驗實例的存在性并實例化自己，然后存儲在靜態(tài)成員變量中，以確保只有一個實例被創(chuàng)建。單例模式模式分析單例模式的實現(xiàn)代碼如下所示：publicclassSingleton{ privatestaticSingletoninstance=null;//靜態(tài)私有成員變量

//私有構(gòu)造函數(shù)

privateSingleton() { }

//靜態(tài)公有工廠方法，返回唯一實例

publicstaticSingletongetInstance() { if(instance==null) instance=newSingleton(); returninstance; }}單例模式模式分析在單例模式的實現(xiàn)過程中，需要注意如下三點：單例類的構(gòu)造函數(shù)為私有；提供一個自身的靜態(tài)私有成員變量；提供一個公有的靜態(tài)工廠方法。單例模式單例模式實例與解析實例一：身份證號碼在現(xiàn)實生活中，居民身份證號碼具有唯一性，同一個人不允許有多個身份證號碼，第一次申請身份證時將給居民分配一個身份證號碼，如果之后因為遺失等原因補辦時，還是使用原來的身份證號碼，不會產(chǎn)生新的號碼。現(xiàn)使用單例模式模擬該場景。單例模式單例模式實例與解析實例一：身份證號碼單例模式模式優(yōu)缺點單例模式的優(yōu)點提供了對唯一實例的受控訪問。因為單例類封裝了它的唯一實例，所以它可以嚴(yán)格控制客戶怎樣以及何時訪問它，并為設(shè)計及開發(fā)團隊提供了共享的概念。由于在系統(tǒng)內(nèi)存中只存在一個對象，因此可以節(jié)約系統(tǒng)資源，對于一些需要頻繁創(chuàng)建和銷毀的對象，單例模式無疑可以提高系統(tǒng)的性能。允許可變數(shù)目的實例。我們可以基于單例模式進行擴展，使用與單例控制相似的方法來獲得指定個數(shù)的對象實例。單例模式模式適用環(huán)境在以下情況下可以使用單例模式：系統(tǒng)只需要一個實例對象，如系統(tǒng)要求提供一個唯一的序列號生成器，或者需要考慮資源消耗太大而只允許創(chuàng)建一個對象?？蛻粽{(diào)用類的單個實例只允許使用一個公共訪問點，除了該公共訪問點，不能通過其他途徑訪問該實例。在一個系統(tǒng)中要求一個類只有一個實例時才應(yīng)當(dāng)使用單例模式。反過來，如果一個類可以有幾個實例共存，就需要對單例模式進行改進，使之成為多例模式。結(jié)構(gòu)型模式結(jié)構(gòu)型模式簡介適配器模式(Adapter)橋接模式(Bridge)組合模式(Composite)裝飾模式(Decorator)外觀模式(Facade)享元模式(Flyweight)代理模式(Proxy)結(jié)構(gòu)型模式結(jié)構(gòu)型模式概述結(jié)構(gòu)型模式(StructuralPattern)描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)，就像搭積木，可以通過簡單積木的組合形成復(fù)雜的、功能更為強大的結(jié)構(gòu)。結(jié)構(gòu)型模式結(jié)構(gòu)型模式概述結(jié)構(gòu)型模式可以分為類結(jié)構(gòu)型模式和對象結(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)用其方法。適配器模式適配器模式模式動機適配器模式模式動機在軟件開發(fā)中采用類似于電源適配器的設(shè)計和編碼技巧被稱為適配器模式。通常情況下，客戶端可以通過目標(biāo)類的接口訪問它所提供的服務(wù)。有時，現(xiàn)有的類可以滿足客戶類的功能需要，但是它所提供的接口不一定是客戶類所期望的，這可能是因為現(xiàn)有類中方法名與目標(biāo)類中定義的方法名不一致等原因所導(dǎo)致的。在這種情況下，現(xiàn)有的接口需要轉(zhuǎn)化為客戶類期望的接口，這樣保證了對現(xiàn)有類的重用。如果不進行這樣的轉(zhuǎn)化，客戶類就不能利用現(xiàn)有類所提供的功能，適配器模式可以完成這樣的轉(zhuǎn)化。適配器模式模式動機在適配器模式中可以定義一個包裝類，包裝不兼容接口的對象，這個包裝類指的就是適配器(Adapter)，它所包裝的對象就是適配者(Adaptee)，即被適配的類。適配器提供客戶類需要的接口，適配器的實現(xiàn)就是把客戶類的請求轉(zhuǎn)化為對適配者的相應(yīng)接口的調(diào)用。也就是說：當(dāng)客戶類調(diào)用適配器的方法時，在適配器類的內(nèi)部將調(diào)用適配者類的方法，而這個過程對客戶類是透明的，客戶類并不直接訪問適配者類。因此，適配器可以使由于接口不兼容而不能交互的類可以一起工作。這就是適配器模式的模式動機。適配器模式模式定義適配器模式(AdapterPattern)：將一個接口轉(zhuǎn)換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)。適配器模式既可以作為類結(jié)構(gòu)型模式，也可以作為對象結(jié)構(gòu)型模式。適配器模式模式結(jié)構(gòu)適配器模式包含如下角色：Target：目標(biāo)抽象類Adapter：適配器類Adaptee：適配者類Client：客戶類適配器模式模式結(jié)構(gòu)類適配器接口實際工作的類繼承自實際工作的類同時實現(xiàn)（符合）接口適配器模式模式結(jié)構(gòu)對象適配器實例化了Adaptee對象符合要求的接口類適配器模式模式分析典型的類適配器代碼：publicclassAdapter

extendsAdapteeimplementsTarget{ publicvoidrequest() {

specificRequest(); }}適配器模式模式分析典型的對象適配器代碼：publicclassAdapterextendsTarget{ privateAdaptee

adaptee;

publicAdapter(Adapteeadaptee) { this.adaptee=adaptee; }

publicvoidrequest() {

adaptee.specificRequest(); }}適配器模式模式適用環(huán)境在以下情況下可以使用適配器模式：系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要。想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進的類一起工作。適配器模式模式優(yōu)缺點適配器模式的優(yōu)點將目標(biāo)類和適配者類解耦，通過引入一個適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼。增加了類的透明性和復(fù)用性，將具體的實現(xiàn)封裝在適配者類中，對于客戶端類來說是透明的，而且提高了適配者的復(fù)用性。靈活性和擴展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器類，完全符合“開閉原則”。適配器模式模式優(yōu)缺點類適配器模式還具有如下優(yōu)點：由于適配器類是適配者類的子類，因此可以在適配器類中置換一些適配者的方法，使得適配器的靈活性更強。類適配器模式的缺點如下：對于Java、C#等不支持多重繼承的語言，一次最多只能適配一個適配者類，而且目標(biāo)抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標(biāo)接口。適配器模式模式應(yīng)用(1)Sun公司在1996年公開了Java語言的數(shù)據(jù)庫連接工具JDBC，JDBC使得Java語言程序能夠與數(shù)據(jù)庫連接，并使用SQL語言來查詢和操作數(shù)據(jù)。JDBC給出一個客戶端通用的抽象接口，每一個具體數(shù)據(jù)庫引擎（如SQLServer、Oracle、MySQL等）的JDBC驅(qū)動軟件都是一個介于JDBC接口和數(shù)據(jù)庫引擎接口之間的適配器軟件。抽象的JDBC接口和各個數(shù)據(jù)庫引擎API之間都需要相應(yīng)的適配器軟件，這就是為各個不同數(shù)據(jù)庫引擎準(zhǔn)備的驅(qū)動程序。適配器模式模式擴展默認適配器模式適配者接口默認適配器類具體業(yè)務(wù)類

適配器模式模式擴展雙向適配器橋接模式橋接模式模式動機設(shè)想如果要繪制矩形、圓形、橢圓、正方形，我們至少需要4個形狀類，但是如果繪制的圖形需要具有不同的顏色，如紅色、綠色、藍色等，此時至少有如下兩種設(shè)計方案：第一種設(shè)計方案是為每一種形狀都提供一套各種顏色的版本。第二種設(shè)計方案是根據(jù)實際需要對形狀和顏色進行組合。橋接模式模式動機對于有兩個變化維度（即兩個變化的原因）的系統(tǒng)，采用方案二來進行設(shè)計系統(tǒng)中類的個數(shù)更少，且系統(tǒng)擴展更為方便。設(shè)計方案二即是橋接模式的應(yīng)用。橋接模式將繼承關(guān)系轉(zhuǎn)換為關(guān)聯(lián)關(guān)系，從而降低了類與類之間的耦合，減少了代碼編寫量。橋接模式模式動機橋接模式模式分析理解橋接模式，重點需要理解如何將抽象化(Abstraction)與實現(xiàn)化(Implementation)脫耦，使得二者可以獨立地變化。抽象化：抽象化就是忽略一些信息，把不同的實體當(dāng)作同樣的實體對待。在面向?qū)ο笾?，將對象的共同性質(zhì)抽取出來形成類的過程即為抽象化的過程。實現(xiàn)化：針對抽象化給出的具體實現(xiàn)，就是實現(xiàn)化，抽象化與實現(xiàn)化是一對互逆的概念，實現(xiàn)化產(chǎn)生的對象比抽象化更具體，是對抽象化事物的進一步具體化的產(chǎn)物。脫耦：脫耦就是將抽象化和實現(xiàn)化之間的耦合解脫開，或者說是將它們之間的強關(guān)聯(lián)改換成弱關(guān)聯(lián)，將兩個角色之間的繼承關(guān)系改為關(guān)聯(lián)關(guān)系。橋接模式中的所謂脫耦，就是指在一個軟件系統(tǒng)的抽象化和實現(xiàn)化之間使用關(guān)聯(lián)關(guān)系（組合或者聚合關(guān)系）而不是繼承關(guān)系，從而使兩者可以相對獨立地變化，這就是橋接模式的用意。橋接模式模式分析典型的實現(xiàn)類接口代碼：publicinterfaceImplementor{ publicvoidoperationImpl();}橋接模式模式分析典型的抽象類代碼：publicabstractclassAbstraction{ protectedImplementorimpl;

publicvoidsetImpl(Implementorimpl) { this.impl=impl; }

publicabstractvoidoperation();}橋接模式模式分析典型的擴充抽象類代碼：publicclassRefinedAbstractionextendsAbstraction{ publicvoidoperation() { //代碼

impl.operationImpl(); //代碼

}}

橋接模式橋接模式實例與解析實例一：模擬毛筆現(xiàn)需要提供大中小3種型號的畫筆，能夠繪制5種不同顏色，如果使用蠟筆，我們需要準(zhǔn)備3*5=15支蠟筆，也就是說必須準(zhǔn)備15個具體的蠟筆類。而如果使用毛筆的話，只需要3種型號的毛筆，外加5個顏料盒，用3+5=8個類就可以實現(xiàn)15支蠟筆的功能。本實例使用橋接模式來模擬毛筆的使用過程。橋接模式橋接模式實例與解析實例一：模擬毛筆橋接模式橋接模式實例與解析實例二：跨平臺視頻播放器如果需要開發(fā)一個跨平臺視頻播放器，可以在不同操作系統(tǒng)平臺（如Windows、Linux、Unix等）上播放多種格式的視頻文件，常見的視頻格式包括MPEG、RMVB、AVI、WMV等?，F(xiàn)使用橋接模式設(shè)計該播放器。橋接模式橋接模式實例與解析實例二：跨平臺視頻播放器橋接模式模式優(yōu)缺點橋接模式的優(yōu)點分離抽象接口及其實現(xiàn)部分。橋接模式有時類似于多繼承方案，但是多繼承方案違背了類的單一職責(zé)原則（即一個類只有一個變化的原因），復(fù)用性比較差，而且多繼承結(jié)構(gòu)中類的個數(shù)非常龐大，橋接模式是比多繼承方案更好的解決方法。橋接模式提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統(tǒng)。實現(xiàn)細節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細節(jié)。橋接模式模式優(yōu)缺點橋接模式的缺點橋接模式的引入會增加系統(tǒng)的理解與設(shè)計難度，由于聚合關(guān)聯(lián)關(guān)系建立在抽象層，要求開發(fā)者針對抽象進行設(shè)計與編程。橋接模式要求正確識別出系統(tǒng)中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。橋接模式模式應(yīng)用(1)Java語言通過Java虛擬機實現(xiàn)了平臺的無關(guān)性。橋接模式模式應(yīng)用(2)一個Java桌面軟件總是帶有所在操作系統(tǒng)的視感(LookAndFeel)，如果一個Java軟件是在Unix系統(tǒng)上開發(fā)的，那么開發(fā)人員看到的是Motif用戶界面的視感；在Windows上面使用這個系統(tǒng)的用戶看到的是Windows用戶界面的視感；而一個在Macintosh上面使用的用戶看到的則是Macintosh用戶界面的視感，Java語言是通過所謂的Peer架構(gòu)做到這一點的。Java為AWT中的每一個GUI構(gòu)件都提供了一個Peer構(gòu)件，在AWT中的Peer架構(gòu)就使用了橋接模式。橋接模式模式擴展適配器模式與橋接模式的聯(lián)用橋接模式和適配器模式用于設(shè)計的不同階段，橋接模式用于系統(tǒng)的初步設(shè)計，對于存在兩個獨立變化維度的類可以將其分為抽象化和實現(xiàn)化兩個角色，使它們可以分別進行變化；而在初步設(shè)計完成之后，當(dāng)發(fā)現(xiàn)系統(tǒng)與已有類無法協(xié)同工作時，可以采用適配器模式。但有時候在設(shè)計初期也需要考慮適配器模式，特別是那些涉及到大量第三方應(yīng)用接口的情況。橋接模式模式擴展適配器模式與橋接模式的聯(lián)用組合模式組合模式模式動機對于樹形結(jié)構(gòu)，當(dāng)容器對象（如文件夾）的某一個方法被調(diào)用時，將遍歷整個樹形結(jié)構(gòu)，尋找也包含這個方法的成員對象（可以是容器對象，也可以是葉子對象，如子文件夾和文件）并調(diào)用執(zhí)行。（遞歸調(diào)用）由于容器對象和葉子對象在功能上的區(qū)別，在使用這些對象的客戶端代碼中必須有區(qū)別地對待容器對象和葉子對象，而實際上大多數(shù)情況下客戶端希望一致地處理它們，因為對于這些對象的區(qū)別對待將會使得程序非常復(fù)雜。組合模式模式動機組合模式描述了如何將容器對象和葉子對象進行遞歸組合，使得用戶在使用時無須對它們進行區(qū)分，可以一致地對待容器對象和葉子對象，這就是組合模式的模式動機。組合模式模式定義組合模式(CompositePattern)：組合多個對象形成樹形結(jié)構(gòu)以表示“整體-部分”的結(jié)構(gòu)層次。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性。組合模式又可以稱為“整體-部分”(Part-Whole)模式，屬于對象的結(jié)構(gòu)模式，它將對象組織到樹結(jié)構(gòu)中，可以用來描述整體與部分的關(guān)系。組合模式模式結(jié)構(gòu)組合模式模式結(jié)構(gòu)組合模式包含如下角色：Component:抽象構(gòu)件Leaf:葉子構(gòu)件Composite:容器構(gòu)件Client:客戶類組合模式模式分析組合模式的關(guān)鍵是定義了一個抽象構(gòu)件類，它既可以代表葉子，又可以代表容器，而客戶端針對該抽象構(gòu)件類進行編程，無須知道它到底表示的是葉子還是容器，可以對其進行統(tǒng)一處理。同時容器對象與抽象構(gòu)件類之間還建立一個聚合關(guān)聯(lián)關(guān)系，在容器對象中既可以包含葉子，也可以包含容器，以此實現(xiàn)遞歸組合，形成一個樹形結(jié)構(gòu)。組合模式模式分析文件系統(tǒng)組合模式結(jié)構(gòu)圖：組合模式模式分析典型的抽象構(gòu)件角色代碼：publicabstractclassComponent{ publicabstractvoidadd(Componentc); publicabstractvoidremove(Componentc); publicabstractComponentgetChild(inti); publicabstractvoidoperation();}組合模式模式分析典型的葉子構(gòu)件角色代碼：publicclassLeafextendsComponent{ publicvoidadd(Componentc) {//異常處理或錯誤提示}

publicvoidremove(Componentc)

{//異常處理或錯誤提示}

publicComponentgetChild(inti)

{//異常處理或錯誤提示}

publicvoidoperation()

{

//實現(xiàn)代碼

}}

組合模式模式分析典型的容器構(gòu)件角色代碼：publicclassCompositeextendsComponent{ privateArrayListlist=newArrayList();

publicvoidadd(Componentc) { list.add(c); }

publicvoidremove(Componentc) { list.remove(c); }

publicComponentgetChild(inti) { (Component)list.get(i); }

publicvoidoperation() { for(Objectobj:list) { ((Component)obj).operation(); } } }

組合模式組合模式實例與解析實例一：水果盤在水果盤(Plate)中有一些水果，如蘋果(Apple)、香蕉(Banana)、梨子(Pear)，當(dāng)然大水果盤中還可以有小水果盤，現(xiàn)需要對盤中的水果進行遍歷（吃），當(dāng)然如果對一個水果盤執(zhí)行“吃”方法，實際上就是吃其中的水果。使用組合模式模擬該場景。組合模式組合模式實例與解析實例一：水果盤組合模式組合模式實例與解析實例一：水果盤參考代碼(Chapter12Composite\sample01)演示……組合模式組合模式實例與解析實例二：文件瀏覽文件有不同類型，不同類型的文件其瀏覽方式有所區(qū)別，如文本文件和圖片文件的瀏覽方式就不相同。對文件夾的瀏覽實際上就是對其中所包含文件的瀏覽，而客戶端可以一致地對文件和文件夾進行操作，無須關(guān)心它們的區(qū)別。使用組合模式來模擬文件的瀏覽操作。組合模式組合模式實例與解析實例二：文件瀏覽組合模式模式優(yōu)缺點組合模式的優(yōu)點可以清楚地定義分層次的復(fù)雜對象，表示對象的全部或部分層次，使得增加新構(gòu)件也更容易?？蛻舳苏{(diào)用簡單，客戶端可以一致的使用組合結(jié)構(gòu)或其中單個對象。定義了包含葉子對象和容器對象的類層次結(jié)構(gòu)，葉子對象可以被組合成更復(fù)雜的容器對象，而這個容器對象又可以被組合，這樣不斷遞歸下去，可以形成復(fù)雜的樹形結(jié)構(gòu)。更容易在組合體內(nèi)加入對象構(gòu)件，客戶端不必因為加入了新的對象構(gòu)件而更改原有代碼。組合模式模式優(yōu)缺點組合模式的缺點使設(shè)計變得更加抽象，對象的業(yè)務(wù)規(guī)則如果很復(fù)雜，則實現(xiàn)組合模式具有很大挑戰(zhàn)性，而且不是所有的方法都與葉子對象子類都有關(guān)聯(lián)。增加新構(gòu)件時可能會產(chǎn)生一些問題，很難對容器中的構(gòu)件類型進行限制。組合模式模式適用環(huán)境在以下情況下可以使用組合模式：需要表示一個對象整體或部分層次，在具有整體和部分的層次結(jié)構(gòu)中，希望通過一種方式忽略整體與部分的差異，可以一致地對待它們。讓客戶能夠忽略不同對象層次的變化，客戶端可以針對抽象構(gòu)件編程，無須關(guān)心對象層次結(jié)構(gòu)的細節(jié)。對象的結(jié)構(gòu)是動態(tài)的并且復(fù)雜程度不一樣，但客戶需要一致地處理它們。組合模式模式應(yīng)用(1)XML文檔解析<?xmlversion="1.0"?><books><book><author>Carson</author><priceformat="dollar">31.95</price><pubdate>05/01/2001</pubdate></book><pubinfo><publisher>MSPress</publisher><state>WA</state></pubinfo></books>組合模式模式應(yīng)用(2)操作系統(tǒng)中的目錄結(jié)構(gòu)是一個樹形結(jié)構(gòu)，因此在對文件和文件夾進行操作時可以應(yīng)用組合模式，例如殺毒軟件在查毒或殺毒時，既可以針對一個具體文件，也可以針對一個目錄。如果是對目錄查毒或殺毒，將遞歸處理目錄中的每一個子目錄和文件。

組合模式模式應(yīng)用(3)JDK的AWT/Swing是組合模式在Java類庫中的一個典型實際應(yīng)用。組合模式模式擴展更復(fù)雜的組合模式組合模式模式擴展透明組合模式組合模式模式擴展安全組合模式外觀模式外觀模式模式動機引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統(tǒng)之間的復(fù)雜關(guān)系由外觀角色來實現(xiàn)，從而降低了系統(tǒng)的耦合度。外觀模式模式定義外觀模式(FacadePattern)：外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的外觀對象進行，為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。外觀模式又稱為門面模式，它是一種對象結(jié)構(gòu)型模式。外觀模式模式結(jié)構(gòu)外觀模式包含如下角色：Facade:外觀角色SubSystem:子系統(tǒng)角色外觀模式模式結(jié)構(gòu)外觀模式模式分析根據(jù)“單一職責(zé)原則”，在軟件中將一個系統(tǒng)劃分為若干個子系統(tǒng)有利于降低整個系統(tǒng)的復(fù)雜性。一個常見的設(shè)計目標(biāo)是使子系統(tǒng)間的通信和相互依賴關(guān)系達到最小，而達到該目標(biāo)的途徑之一就是引入一個外觀對象，它為子系統(tǒng)的訪問提供了一個簡單而單一的入口。外觀模式也是“迪米特法則”的體現(xiàn)，通過引入一個新的外觀類可以降低原有系統(tǒng)的復(fù)雜度，同時降低客戶類與子系統(tǒng)類的耦合度。外觀模式模式分析外觀模式要求一個子系統(tǒng)的外部與其內(nèi)部的通信通過一個統(tǒng)一的外觀對象進行。外觀類將客戶端與子系統(tǒng)的內(nèi)部復(fù)雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統(tǒng)內(nèi)部的很多對象打交道。外觀模式的目的在于降低系統(tǒng)的復(fù)雜程度。外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關(guān)心子系統(tǒng)的工作細節(jié)，通過外觀角色即可調(diào)用相關(guān)功能。外觀模式模式分析典型的外觀角色代碼：publicclassFacade{privateSubSystemAobj1=newSubSystemA();privateSubSystemBobj2=newSubSystemB();privateSubSystemCobj3=newSubSystemC();publicvoidmethod(){obj1.method();obj2.method();obj3.method();}}

外觀模式外觀模式實例與解析實例一：電源總開關(guān)現(xiàn)在考察一個電源總開關(guān)的例子，以便進一步說明外觀模式。為了使用方便，一個電源總開關(guān)可以控制四盞燈、一個風(fēng)扇、一臺空調(diào)和一臺電視機的啟動和關(guān)閉。通過該電源總開關(guān)可以同時控制上述所有電器設(shè)備，使用外觀模式設(shè)計該系統(tǒng)。外觀模式外觀模式實例與解析實例一：電源總開關(guān)外觀模式外觀模式實例與解析實例二：文件加密某系統(tǒng)需要提供一個文件加密模塊，加密流程包括三個操作，分別是讀取源文件、加密、保存加密之后的文件。讀取文件和保存文件使用流來實現(xiàn)，這三個操作相對獨立，其業(yè)務(wù)代碼封裝在三個不同的類中?，F(xiàn)在需要提供一個統(tǒng)一的加密外觀類，用戶可以直接使用該加密外觀類完成文件的讀取、加密和保存三個操作，而不需要與每一個類進行交互，使用外觀模式設(shè)計該加密模塊。外觀模式外觀模式實例與解析實例二：文件加密外觀模式模式優(yōu)缺點外觀模式的優(yōu)點對客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡單，與之關(guān)聯(lián)的對象也很少。實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系，這使得子系統(tǒng)的組件變化不會影響到調(diào)用它的客戶類，只需要調(diào)整外觀類即可。降低了大型軟件系統(tǒng)中的編譯依賴性，并簡化了系統(tǒng)在不同平臺之間的移植過程，因為編譯一個子系統(tǒng)一般不需要編譯所有其他的子系統(tǒng)。一個子系統(tǒng)的修改對其他子系統(tǒng)沒有任何影響，而且子系統(tǒng)內(nèi)部變化也不會影響到外觀對象。只是提供了一個訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類。外觀模式模式優(yōu)缺點外觀模式的缺點不能很好地限制客戶使用子系統(tǒng)類，如果對客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。外觀模式模式適用環(huán)境在以下情況下可以使用外觀模式：當(dāng)要為一個復(fù)雜子系統(tǒng)提供一個簡單接口時可以使用外觀模式。該接口可以滿足大多數(shù)用戶的需求，而且用戶也可以越過外觀類直接訪問子系統(tǒng)?？蛻舫绦蚺c多個子系統(tǒng)之間存在很大的依賴性。引入外觀類將子系統(tǒng)與客戶以及其他子系統(tǒng)解耦，可以提高子系統(tǒng)的獨立性和可移植性。在層次化結(jié)構(gòu)中，可以使用外觀模式定義系統(tǒng)中每一層的入口，層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。外觀模式模式擴展不要試圖通過外觀類為子系統(tǒng)增加新行為不要通過繼承一個外觀類在子系統(tǒng)中加入新的行為，這種做法是錯誤的。外觀模式的用意是為子系統(tǒng)提供一個集中化和簡化的溝通渠道，而不是向子系統(tǒng)加入新的行為，新的行為的增加應(yīng)該通過修改原有子系統(tǒng)類或增加新的子系統(tǒng)類來實現(xiàn)，不能通過外觀類來實現(xiàn)。外觀模式模式擴展抽象外觀類的引入外觀模式最大的缺點在于違背了“開閉原則”，當(dāng)增加新的子系統(tǒng)或者移除子系統(tǒng)時需要修改外觀類，可以通過引入抽象外觀類在一定程度上解決該問題，客戶端針對抽象外觀類進行編程。對于新的業(yè)務(wù)需求，不修改原有外觀類，而對應(yīng)增加一個新的具體外觀類，由新的具體外觀類來關(guān)聯(lián)新的子系統(tǒng)對象，同時通過修改配置文件來達到不修改源代碼并更換外觀類的目的。外觀模式模式擴展抽象外觀類的引入行為型模式行為型模式簡介職責(zé)鏈模式(ChainofResponsibility)命令模式(Command)解釋器模式(Interpreter)迭代器模式(Iterator)中介者模式(Mediator)備忘錄模式(Memento)觀察者模式(Observer)狀態(tài)模式(State)策略模式(Strategy)模板方法模式(TemplateMethod)訪問者模式(Visitor)行為型模式行為型模式概述行為型模式(BehavioralPattern)是對在不同的對象之間劃分責(zé)任和算法的抽象化。行為型模式不僅僅關(guān)注類和對象的結(jié)構(gòu)，而且重點關(guān)注它們之間的相互作用。通過行為型模式，可以更加清晰地劃分類與對象的職責(zé)，并研究系統(tǒng)在運行時實例對象之間的交互。在系統(tǒng)運行時，對象并不是孤立的，它們可以通過相互通信與協(xié)作完成某些復(fù)雜功能，一個對象在運行時也將影響到其他對象的運行。行為型模式行為型模式概述行為型模式分為類行為型模式和對象行為型模式兩種：類行為型模式：類的行為型模式使用繼承關(guān)系在幾個類之間分配行為，類行為型模式主要通過多態(tài)等方式來分配父類與子類的職責(zé)。對象行為型模式：對象的行為型模式則使用對象的聚合關(guān)聯(lián)關(guān)系來分配行為，對象行為型模式主要是通過對象關(guān)聯(lián)等方式來分配兩個或多個類的職責(zé)。根據(jù)“合成復(fù)用原則”，系統(tǒng)中要盡量使用關(guān)聯(lián)關(guān)系來取代繼承關(guān)系，因此大部分行為型設(shè)計模式都屬于對象行為型設(shè)計模式。職責(zé)鏈模式職責(zé)鏈模式模式動機職責(zé)鏈模式模式動機職責(zé)鏈可以是一條直線、一個環(huán)或者一個樹形結(jié)構(gòu)，最常見的職責(zé)鏈?zhǔn)侵本€型，即沿著一條單向的鏈來傳遞請求。鏈上的每一個對象都是請求處理者，職責(zé)鏈模式可以將請求的處理者組織成一條鏈，并使請求沿著鏈傳遞，由鏈上的處理者對請求進行相應(yīng)的處理客戶端無須關(guān)心請求的處理細節(jié)以及請求的傳遞，只需將請求發(fā)送到鏈上即可，將請求的發(fā)送者和請求的處理者解耦。這就是職責(zé)鏈模式的模式動機。職責(zé)鏈模式模式定義職責(zé)鏈模式(ChainofResponsibilityPattern)：避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。由于英文翻譯的不同，職責(zé)鏈模式又稱為責(zé)任鏈模式，它是一種對象行為型模式。職責(zé)鏈模式模式結(jié)構(gòu)職責(zé)鏈模式包含如下角色：Handler:抽象處理者ConcreteHandler:具體處理者Client:客戶類職責(zé)鏈模式模式結(jié)構(gòu)后續(xù)處理類職責(zé)鏈模式模式分析在職責(zé)鏈模式里，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這條鏈上傳遞，直到鏈上的某一個對象處理此請求為止。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統(tǒng)可以在不影響客戶端的情況下動態(tài)地重新組織鏈和分配責(zé)任。職責(zé)鏈模式職責(zé)鏈模式實例與解析實例：審批假條某OA系統(tǒng)需要提供一個假條審批的模塊，如果員工請假天數(shù)小于3天，主任可以審批該假條；如果員工請假天數(shù)大于等于3天，小于10天，經(jīng)理可以審批；如果員工請假天數(shù)大于等于10天，小于30天，總經(jīng)理可以審批；如果超過30天，總經(jīng)理也不能審批，提示相應(yīng)的拒絕信息。職責(zé)鏈模式職責(zé)鏈模式實例與解析實例：審批假條職責(zé)鏈模式模式優(yōu)缺點職責(zé)鏈模式的優(yōu)點降低耦合度可簡化對象的相互連接增強給對象指派職責(zé)的靈活性增加新的請求處理類很方便職責(zé)鏈模式模式優(yōu)缺點職責(zé)鏈模式的缺點不能保證請求一定被接收。（或者最后提示無法處理？）系統(tǒng)性能將受到一定影響，而且在進行代碼調(diào)試時不太方便；可能會造成循環(huán)調(diào)用。職責(zé)鏈模式模式適用環(huán)境在以下情況下可以使用職責(zé)鏈模式：有多個對象可以處理同一個請求，具體哪個對象處理該請求由運行時刻自動確定。在不明確指定接收者的情況下，向多個對象中的一個提交一個請求?？蓜討B(tài)指定一組對象處理請求。職責(zé)鏈模式模式應(yīng)用(1)Java中的異常處理機制try{…… }catch(ArrayIndexOutOfBoundsExceptione1){……}catch(ArithmeticExceptione2){……}catch(IOExceptione3){……}finally{……}職責(zé)鏈模式模式應(yīng)用(2)早期的JavaAWT事件模型