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

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

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

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

來(lái)對(duì)對(duì)象進(jìn)行定義。而在運(yùn)行時(shí)再確定其子類類型，用子類對(duì)象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

privateSingleton() { }

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

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

extendsAdapteeimplementsTarget{ publicvoidrequest() {

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

adaptee;

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

publicvoidrequest() {

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

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

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

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

impl.operationImpl(); //代碼

}}

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

publicvoidremove(Componentc)

{//異常處理或錯(cuò)誤提示}

publicComponentgetChild(inti)

{//異常處理或錯(cuò)誤提示}

publicvoidoperation()

{

//實(shí)現(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(); } } }

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

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

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