分布式體系結(jié)構(gòu)

主要內(nèi)容軟件體系結(jié)構(gòu)的基本概念典型的軟件體系結(jié)構(gòu)風(fēng)格特定領(lǐng)域的軟件體系結(jié)構(gòu)分布式系統(tǒng)結(jié)構(gòu)體系結(jié)構(gòu)框架設(shè)計(jì)模式用戶界面設(shè)計(jì)1什么是軟件體系結(jié)構(gòu)？PaulClements;FelixBachmann,LenBass,DavidGarlan,JamesIvers,ReedLittle,PauloMerson,RobertNord,JudithStafford(2010).DocumentingSoftwareArchitectures:ViewsandBeyond,SecondEdition.Boston:Addison-Wesley.ISBN

0-321-55268-7.“thehighlevelstructuresofasoftwaresystem.Itcanbedefinedasthesetofstructuresneededtoreasonaboutthesoftwaresystem,whichcomprisethesoftwareelements,therelationsbetweenthem,andthepropertiesofbothelementsandrelations”這一定義強(qiáng)調(diào)在任一體系結(jié)構(gòu)表述中“軟件構(gòu)件”的角色。1．模式建筑師C.Alexander對(duì)模式給出的經(jīng)典定義：每個(gè)模式都描述了一個(gè)在我們的環(huán)境中不斷出現(xiàn)的問題及該問題的解決方案。（1）體系結(jié)構(gòu)模式(architecturalpattern)：軟件系統(tǒng)的基本結(jié)構(gòu)方案，包含了:(a)一組預(yù)定義的子系統(tǒng)及其責(zé)任、(b)用于組織和管理這些子系統(tǒng)的規(guī)則。如：OSI參考模型（2）設(shè)計(jì)模式(designpattern)：為軟件系統(tǒng)的子系統(tǒng)、構(gòu)件或者構(gòu)件之間的關(guān)系提供一個(gè)精煉的解決方案，描述了在特定環(huán)境下，用于解決通用軟件設(shè)計(jì)問題的構(gòu)件以及這些構(gòu)件相互通信時(shí)的各種結(jié)構(gòu)。

GangofFour(GoF)提出的23種設(shè)計(jì)模式。體系結(jié)構(gòu)模式、風(fēng)格和框架Gang-of-Four’952．風(fēng)格風(fēng)格是帶有一種傾向性的模式。同一個(gè)問題可以有不同的解決問題的方式，但根據(jù)經(jīng)驗(yàn)，通常會(huì)強(qiáng)烈傾向于采用特定的模式，這就是風(fēng)格。每種風(fēng)格描述一種系統(tǒng)范疇：（1）一組構(gòu)件（如數(shù)據(jù)庫(kù)、計(jì)算模塊）完成系統(tǒng)需要的某種功能；（2）一組連接件，它們能使構(gòu)件間實(shí)現(xiàn)通信；（3）約束，定義構(gòu)件如何集成為一個(gè)系統(tǒng)；（4）語義模型，它能使設(shè)計(jì)者通過分析系統(tǒng)構(gòu)成的性質(zhì)來理解系統(tǒng)的整體性質(zhì)。對(duì)體系結(jié)構(gòu)風(fēng)格的研究和實(shí)踐為大粒度的軟件復(fù)用提供了可能。3．框架隨著應(yīng)用的發(fā)展和完善，某些帶有整體性的應(yīng)用模式被逐漸固定下來，形成特定的框架，包括基本構(gòu)成元素和關(guān)系。

框架是特定領(lǐng)域問題的體系結(jié)構(gòu)模式，框架定義了基本構(gòu)成單元和關(guān)系后，開發(fā)者就可以集中精力解決業(yè)務(wù)邏輯問題。在組織形式上，框架是一個(gè)待實(shí)例化的完整系統(tǒng)，定義了軟件系統(tǒng)的元素和關(guān)系，創(chuàng)建了基本的模塊，定義了涉及功能更改和擴(kuò)充的插件位置。典型的框架例子有MVC框架和Struts框架。

輸入數(shù)據(jù)經(jīng)過一系列的計(jì)算和操作構(gòu)件的變換形成輸出數(shù)據(jù)如：管道/過濾器、批處理序列數(shù)據(jù)流風(fēng)格

管道/過濾器結(jié)構(gòu)

2典型的體系結(jié)構(gòu)風(fēng)格管道/過濾器風(fēng)格具有以下優(yōu)點(diǎn)：（1）良好的隱蔽性、高內(nèi)聚、低耦合（2）允許設(shè)計(jì)者將整個(gè)系統(tǒng)的輸入/輸出行為看成是多個(gè)過濾器的行為的簡(jiǎn)單合成。（3）支持軟件復(fù)用。只要提供適合在兩個(gè)過濾器之間傳送的數(shù)據(jù)，任何兩個(gè)過濾器都可被連接起來。（4）系統(tǒng)維護(hù)和增強(qiáng)系統(tǒng)性能簡(jiǎn)單。新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進(jìn)的過濾器替換掉。（5）易于吞吐量分析、診斷死鎖（6）支持并行執(zhí)行。每個(gè)過濾器是作為一個(gè)單獨(dú)的任務(wù)完成，因此可與其他任務(wù)并行執(zhí)行。管道/過濾器風(fēng)格有以下缺點(diǎn)：（1）通常導(dǎo)致進(jìn)程成為批處理的結(jié)構(gòu)。這是因?yàn)殡m然過濾器可增量式地處理數(shù)據(jù)，但它們是獨(dú)立的，所以設(shè)計(jì)者必須將每個(gè)過濾器看成一個(gè)完整的從輸入到輸出的轉(zhuǎn)換。（2）不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時(shí)，這個(gè)問題尤為嚴(yán)重。（3）因?yàn)樵跀?shù)據(jù)傳輸上沒有通用的標(biāo)準(zhǔn)，每個(gè)過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編寫過濾器的復(fù)雜性。調(diào)用—返回風(fēng)格

1．主程序/子程序體系結(jié)構(gòu)

將功能分解為一個(gè)控制層次，其中“主”程序調(diào)用一組程序構(gòu)件，這些程序構(gòu)件又去調(diào)用別的程序構(gòu)件。這種結(jié)構(gòu)總體上為樹狀結(jié)構(gòu)，可以在底層存在公共模塊。RemoteProcedureCall(RPC)MoreforRPCProtocol:XML/JSON-RPCsynchronous/asynchronousreadsynchronous/asynchronouswritepublish/subscribe……主程序/子程序體系結(jié)構(gòu)的優(yōu)點(diǎn):（1）可以使用自頂向下，逐步分解的方法得到體系結(jié)構(gòu)圖，典型的拓?fù)浣Y(jié)構(gòu)為樹狀結(jié)構(gòu)。使用過程調(diào)用作為程序之間的交互機(jī)制。（2）采用程序設(shè)計(jì)語言支持的單線程控制。主要缺點(diǎn):（1）子程序的正確性難于判斷，需層次推理處理嵌套。（2）子系統(tǒng)的結(jié)構(gòu)不清晰。通?？梢詫⒍鄠€(gè)子程序合成為一個(gè)模塊。2．層次結(jié)構(gòu)整個(gè)系統(tǒng)被組織成一個(gè)分層結(jié)構(gòu)，每一層為上層提供服務(wù)，并作為下一層的客戶。3.倉(cāng)庫(kù)風(fēng)格

如：數(shù)據(jù)庫(kù)系統(tǒng)、超文本系統(tǒng)和黑板系統(tǒng)。在這種風(fēng)格中，數(shù)據(jù)倉(cāng)庫(kù)（如文件或數(shù)據(jù)庫(kù)）位于這種體系結(jié)構(gòu)的中心，其他構(gòu)件會(huì)經(jīng)常訪問該數(shù)據(jù)倉(cāng)庫(kù)，并對(duì)倉(cāng)庫(kù)中的數(shù)據(jù)進(jìn)行增刪改查操作特定的應(yīng)用需要特定的體系結(jié)構(gòu)模型，稱為領(lǐng)域相關(guān)的體系結(jié)構(gòu)。通用模型(genericmodel)參考模型(referencemodel)3特定領(lǐng)域的軟件體系結(jié)構(gòu)通用模型

從許多實(shí)際系統(tǒng)中抽象出來的一般模型封裝了這些系統(tǒng)的主要特征。例如，許多圖書館開發(fā)了自己的圖書館館藏/流通系統(tǒng)，若把它們的共同功能抽取出來并創(chuàng)建一個(gè)讓所有圖書館都認(rèn)可的系統(tǒng)體系結(jié)構(gòu)模型，就成為圖書館通用模型。描述了一個(gè)理想化的包含了系統(tǒng)應(yīng)具有的所有特征的軟件體系結(jié)構(gòu)。它是更抽象且是描述一大類系統(tǒng)的模型，并且為設(shè)計(jì)者提供有關(guān)某類系統(tǒng)設(shè)計(jì)的一般指導(dǎo)。

參考模型

例：OSI參考模型

以上兩種不同類型的模型之間并不存在嚴(yán)格的區(qū)別，也可以將通用模型視為參考模型。通用模型可以直接在設(shè)計(jì)中復(fù)用而參考模型一般是用于領(lǐng)域概念間的交流和對(duì)可能的體系結(jié)構(gòu)做出比較。通用模型通常是經(jīng)過“自下而上”地對(duì)已有系統(tǒng)的抽象參考模型是“由上到下”產(chǎn)生的4分布式體系結(jié)構(gòu)在集中式計(jì)算技術(shù)時(shí)代廣泛使用的是大型機(jī)/小型機(jī)計(jì)算模型。20世紀(jì)80年代以后，集中式結(jié)構(gòu)逐漸被以PC為主的微機(jī)網(wǎng)絡(luò)所取代。個(gè)人計(jì)算機(jī)和工作站的采用，永遠(yuǎn)改變了大型機(jī)/小型機(jī)計(jì)算模型，從而產(chǎn)生了分布式計(jì)算模型。分布式計(jì)算模型主要具有以下優(yōu)點(diǎn)：(1)資源共享。分布式系統(tǒng)允許硬件、軟件等資源共享使用。(2)經(jīng)濟(jì)性。(3)性能與可擴(kuò)展性。(4)固有分布性。(5)健壯性。

系統(tǒng)由許多進(jìn)程組成，這些進(jìn)程可以在不同的處理器上并行運(yùn)行，極大地提高系統(tǒng)性能。大型實(shí)時(shí)系統(tǒng)需要實(shí)時(shí)采集信息，并利用采集到的信息進(jìn)行決策，然后發(fā)送信號(hào)給執(zhí)行機(jī)構(gòu)。雖然，信息采集、決策制定和執(zhí)行控制這些進(jìn)程可以在同一臺(tái)處理器上統(tǒng)一調(diào)度執(zhí)行，但使用多處理器能夠提高系統(tǒng)性能，減少響應(yīng)時(shí)間。多處理器體系結(jié)構(gòu)

IBMSystemZ10EC,USD230MClient/Server體系結(jié)構(gòu)是基于資源不對(duì)等產(chǎn)生的，且為實(shí)現(xiàn)資源共享而提出來的由服務(wù)器、客戶機(jī)和網(wǎng)絡(luò)三部分組成。在C/S體系結(jié)構(gòu)中，客戶機(jī)可以通過遠(yuǎn)程調(diào)用來獲取服務(wù)器提供的服務(wù)客戶機(jī)必須知道可用的服務(wù)器的名字及它們所提供的服務(wù)，而服務(wù)器不需要知道客戶機(jī)的身份，也不需要知道有多少臺(tái)服務(wù)器在運(yùn)行。

客戶/服務(wù)器體系結(jié)構(gòu)

傳統(tǒng)的C/S體系結(jié)構(gòu)分為兩層ThinClientFatClient（1）瘦客戶機(jī)模型。數(shù)據(jù)管理和應(yīng)用邏輯都在服務(wù)器上執(zhí)行，客戶機(jī)只負(fù)責(zé)信息表示部分。缺點(diǎn)：將繁重的處理負(fù)荷放在了服務(wù)器和網(wǎng)絡(luò)上，服務(wù)器負(fù)責(zé)所有的計(jì)算，但增加了客戶機(jī)和服務(wù)器之間的網(wǎng)絡(luò)流量。

（2）胖客戶機(jī)模型。服務(wù)器只負(fù)責(zé)對(duì)數(shù)據(jù)的管理?？蛻魴C(jī)軟件實(shí)現(xiàn)了應(yīng)用邏輯和與系統(tǒng)用戶的交互。充分利用客戶機(jī)的處理能力，利于分布式處理。但隨著系統(tǒng)規(guī)模的擴(kuò)大和復(fù)雜性提高，暴露出了以下缺點(diǎn)：開發(fā)成本較高。用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。軟件移植困難。軟件維護(hù)和升級(jí)困難。

為了解決以上問題，三層C/S體系結(jié)構(gòu)應(yīng)運(yùn)而生：增加了應(yīng)用服務(wù)器（處理應(yīng)用邏輯）。系統(tǒng)分成表示層、應(yīng)用邏輯層和數(shù)據(jù)層三個(gè)部分。瀏覽器/服務(wù)器(Browser/Server,B/S)風(fēng)格是三層體系結(jié)構(gòu)的一種實(shí)現(xiàn)方式，其具體結(jié)構(gòu)為瀏覽器/Web服務(wù)器/數(shù)據(jù)庫(kù)服務(wù)器。Example:InternetBankingSummaryofC/SArchitecture動(dòng)機(jī)：在C/S模型中，客戶機(jī)和服務(wù)器的地位是不同的目的：消除客戶機(jī)與服務(wù)器之間的差別，提高系統(tǒng)的伸縮性以及有效地均衡負(fù)載分布式對(duì)象的實(shí)質(zhì)是在分布式異構(gòu)環(huán)境下建立應(yīng)用系統(tǒng)框架和對(duì)象構(gòu)件，它將應(yīng)用服務(wù)分割成具有完整邏輯含義的獨(dú)立子模塊（稱為構(gòu)件）各個(gè)構(gòu)件可放在同一臺(tái)服務(wù)器或分布在多臺(tái)服務(wù)器上運(yùn)行模塊之間通過中間件互相通信。分布式對(duì)象體系結(jié)構(gòu)

這個(gè)中間件稱為軟件總線或?qū)ο笳?qǐng)求代理(ObjectRequestBroker)，它的作用是在對(duì)象之間提供一個(gè)無縫接口。降低主服務(wù)器的負(fù)荷、共享網(wǎng)絡(luò)資源、平衡網(wǎng)絡(luò)中計(jì)算機(jī)業(yè)務(wù)處理的分配，提高計(jì)算機(jī)系統(tǒng)協(xié)同處理能力使應(yīng)用的實(shí)現(xiàn)更為靈活。構(gòu)件是一些獨(dú)立的代碼封裝體，在分布計(jì)算的環(huán)境下可以是一個(gè)簡(jiǎn)單的對(duì)象，但大多數(shù)情況下是一組相關(guān)的對(duì)象組合體，提供一定的服務(wù)構(gòu)件位置透明、語言獨(dú)立、平臺(tái)獨(dú)立，可互相發(fā)送消息，實(shí)現(xiàn)請(qǐng)求服務(wù)構(gòu)件之間并不存在客戶機(jī)與服務(wù)器的界限，接受服務(wù)者扮演客戶機(jī)的角色，提供服務(wù)者就是服務(wù)器。當(dāng)前主流的分布式對(duì)象技術(shù)規(guī)范有OMG的CORBA、Microsoft公司的.NET和Sun公司的J2EE。Example:DataMiningSystem5體系結(jié)構(gòu)框架MVC框架

即模型—視圖—控制器(model-view-controller)

它強(qiáng)調(diào)將用戶輸入、數(shù)據(jù)模型和數(shù)據(jù)表示的方式分開設(shè)計(jì)

模型:核心數(shù)據(jù)和功能視圖:數(shù)據(jù)表示

控制器:輸入/輸出控制1.模型對(duì)象模型對(duì)象獨(dú)立于外在顯示內(nèi)容和形式，代表應(yīng)用領(lǐng)域中的業(yè)務(wù)實(shí)體和業(yè)務(wù)規(guī)則。模型對(duì)象的變化通過事件處理通知視圖和控制器對(duì)象。2.視圖對(duì)象視圖對(duì)象代表GUI對(duì)象，并且以用戶需要的格式表示模型狀態(tài)，是交互系統(tǒng)與外界的接口。視圖對(duì)象可以包含子視圖，子視圖用于顯示模型的不同部分。通常每個(gè)視圖對(duì)象對(duì)應(yīng)一個(gè)控制器對(duì)象。3.控制器對(duì)象控制器對(duì)象代表鼠標(biāo)和鍵盤事件。它處理用戶的輸入行為并給模型發(fā)送業(yè)務(wù)事件，再將業(yè)務(wù)事件解析為模型應(yīng)執(zhí)行的動(dòng)作；同時(shí)，模型的更新與修改也將通過控制器來通知視圖，從而保持各個(gè)視圖與模型的一致性。

在MVC框架的基礎(chǔ)上進(jìn)行擴(kuò)展得到的。J2EE體系結(jié)構(gòu)框架

J2EE的核心體系結(jié)構(gòu)框架

ControllerViewModel客戶層：用戶通過客戶層與系統(tǒng)交互。該層可以是各種類型的客戶端。例如，可編程客戶端（如基于JavaSwing的客戶端或applet），純Web瀏覽器客戶端，WML移動(dòng)客戶端等。資源層：資源層可以是企業(yè)數(shù)據(jù)庫(kù)，電子商務(wù)解決方案中的外部企業(yè)系統(tǒng)，或者是外部SOA服務(wù)。數(shù)據(jù)可以分布在多個(gè)服務(wù)器上。J2EE模型是分層結(jié)構(gòu)，中間的3層（表示層，業(yè)務(wù)層，集成層）包含應(yīng)用程序構(gòu)件，客戶層和資源層處于應(yīng)用程序的外圍。表示層：也稱為Web層或服務(wù)器端表示層，用戶通過表示層來訪問應(yīng)用程序。在基于Web的應(yīng)用系統(tǒng)中，表示層由用戶界面代碼和運(yùn)行于Web服務(wù)器或應(yīng)用服務(wù)器上的過程組成。參考MVC框架，表示層包括視圖(View)構(gòu)件和控制器構(gòu)件(Controller)。業(yè)務(wù)層：業(yè)務(wù)層包含表示層中的控制器構(gòu)件沒有實(shí)現(xiàn)的一部分應(yīng)用邏輯。它負(fù)責(zé)確認(rèn)和執(zhí)行企業(yè)范圍內(nèi)的業(yè)務(wù)規(guī)則和事務(wù)，并管理從資源層加載到應(yīng)用程序高速緩存中的業(yè)務(wù)對(duì)象。集成層：集成層負(fù)責(zé)建立和維護(hù)與數(shù)據(jù)源的連接。例如，通過JDBC與數(shù)據(jù)庫(kù)進(jìn)行通信，利用Java消息服務(wù)（JMS）與外部系統(tǒng)聯(lián)合。

表示—控制—中介者—實(shí)體—基礎(chǔ)（presentation-control-mediator-entity-foundation）垂直層次的分層體系結(jié)構(gòu)框架。包含4層：表示層、控制層、領(lǐng)域?qū)雍突A(chǔ)層。領(lǐng)域?qū)影瑑蓚€(gè)預(yù)定義包：實(shí)體（entity）包和中介者（mediator）包。

PCMEF框架中包的依賴性主要是向下依賴性。表示層依賴于控制層，控制層依賴于領(lǐng)域?qū)?，中介者包依賴于?shí)體包和基礎(chǔ)層。

PCMEF框架

表示層:包含定義GUI對(duì)象的類?？刂茖?處理表示層的請(qǐng)求，負(fù)責(zé)大多數(shù)程序邏輯、算法、主要計(jì)算以及為每個(gè)用戶維持會(huì)話狀態(tài)。領(lǐng)域?qū)?其實(shí)體包處理控制請(qǐng)求,中介者包用于創(chuàng)建一個(gè)協(xié)調(diào)實(shí)體類和基礎(chǔ)類的通信通道?；A(chǔ)層:負(fù)責(zé)與數(shù)據(jù)庫(kù)和Web服務(wù)的通信。設(shè)計(jì)模式什么是設(shè)計(jì)模式？創(chuàng)建型模式結(jié)構(gòu)型模式行為型模式廣義講，設(shè)計(jì)模式是可解決一類軟件問題并能重復(fù)使用的設(shè)計(jì)方案狹義講，設(shè)計(jì)模式是對(duì)被用來在特定場(chǎng)景下解決一般設(shè)計(jì)問題的類和相互通信的對(duì)象的描述。是在類和對(duì)象的層次描述的可重復(fù)使用的軟件設(shè)計(jì)問題的解決方案模式體現(xiàn)的是程序整體的構(gòu)思，也會(huì)出現(xiàn)在分析或者是概要設(shè)計(jì)階段

模式的核心思想是通過增加抽象層，把變化部分從那些不變部分里分離出來什么是設(shè)計(jì)模式模式名稱(PatternName)問題(Problem)：描述應(yīng)該在何時(shí)使用模式。解釋了設(shè)計(jì)問題和問題存在的前因后果,可能還描述模式必須滿足的先決條件解決方案(Solution)：描述了設(shè)計(jì)的組成成分、相互關(guān)系及各自的職責(zé)和協(xié)作方式。模式就像一個(gè)模板，可應(yīng)用于多種場(chǎng)合，所以解決方案并不描述一個(gè)具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問題的抽象描述和解決問題所采用的元素組合（類和對(duì)象）效果(Consequences)：描述模式的應(yīng)用效果及使用模式應(yīng)權(quán)衡的問題模式的4大基本要素單一職責(zé)原則(SingleResponsibility)“開-閉”原則(OpenClosed)里氏代換原則(LiskovSubstitution)接口隔離原則(InterfaceSegregation)依賴倒置原則(DependencyInversion)設(shè)計(jì)模式的S.O.L.I.D.原則設(shè)計(jì)模式就是實(shí)現(xiàn)了上述原則，從而達(dá)到代碼復(fù)用、增加可維護(hù)性的目的定義：對(duì)功能擴(kuò)展是開放的，對(duì)修改是關(guān)閉的。在進(jìn)行擴(kuò)展的時(shí)候，不需要對(duì)原來的程序進(jìn)行修改好處：靈活可用，可加入新功能，新模塊滿足不斷變化的新需求由于不修改軟件原來的模塊，不用擔(dān)心軟件的穩(wěn)定性開閉原則（OCP）主要原則抽象原則：把系統(tǒng)的所有可能的行為抽象成一個(gè)底層；由于可從抽象層導(dǎo)出多個(gè)具體類來改變系統(tǒng)行為，因此對(duì)于可變部分，系統(tǒng)設(shè)計(jì)對(duì)擴(kuò)展是開放的可變性封裝原則：對(duì)系統(tǒng)所有可能發(fā)生變化的部分進(jìn)行評(píng)估和分類，每一個(gè)可變的因素都單獨(dú)進(jìn)行封裝就一個(gè)類而言，應(yīng)僅有一個(gè)引起它變化的原因每一個(gè)引起類變化的原因就是一個(gè)職責(zé)，當(dāng)類具有多職責(zé)時(shí)，應(yīng)把多余職責(zé)分離出去，分別創(chuàng)建類來完成每一個(gè)職責(zé)都是一個(gè)變化的軸線，當(dāng)需求變化時(shí)會(huì)反映為類的職責(zé)的變化舉例interfaceModem{publicvoiddial(Stringpno);publicvoidhangup();publicsend(charc);publiccharrecv();}Modem類有兩個(gè)職責(zé)：連接管理和數(shù)據(jù)通信，應(yīng)將它們分離單一職責(zé)原則（SRP）listKov替換原則（LSP）

定義：“繼承必須確保父類所擁有的性質(zhì)在子類中仍然成立”，當(dāng)一個(gè)子類的實(shí)例能夠替換任何其父類的實(shí)例時(shí)，它們之間才具有is-a-kind-of-A關(guān)系只有當(dāng)派生類可以替換掉其基類，而軟件功能不受影響時(shí)，基類才能真正被復(fù)用，派生類也才能夠在基類的基礎(chǔ)上增加新的行為本質(zhì)：在同一個(gè)繼承體系中的對(duì)象應(yīng)該有共同的行為特征例子：企鵝是鳥嗎？生物學(xué)：企鵝屬于鳥類

LSP原則：企鵝不屬于鳥類，因?yàn)槠簌Z不會(huì)“飛”違反LSP的后果：有可能需要修改客戶代碼依賴倒置原則（DIP）定義：高層模塊不應(yīng)依賴低層模塊，二者都應(yīng)該依賴于抽象高層模塊只應(yīng)包含重要的業(yè)務(wù)模型和策略選擇低層模塊則是不同業(yè)務(wù)和策略的實(shí)現(xiàn)高層抽象不依賴高層和低層模塊的具體實(shí)現(xiàn)，最多只依賴于低層的抽象低層抽象和實(shí)現(xiàn)也只依賴于高層抽象輔助原則任何變量都不應(yīng)該持有一個(gè)指向具體類的引用任何類都不應(yīng)該從具體類派生任何方法都不應(yīng)覆蓋其任何基類中已經(jīng)實(shí)現(xiàn)了的方法接口隔離原則（ISP）多個(gè)和客戶相關(guān)的接口要好于一個(gè)通用接口如果一個(gè)類有幾個(gè)使用者，與其讓這個(gè)類載入所有使用者需要使用的所有方法，還不如為每個(gè)使用者創(chuàng)建一個(gè)特定接口，并讓該類分別實(shí)現(xiàn)這些接口ISPExampleISPExample

創(chuàng)建型模式結(jié)構(gòu)型模式行為型模式根據(jù)模式的范圍分，模式用于類還是用于對(duì)象類模式：處理類和子類之間的關(guān)系，這些關(guān)系通過繼承建立，是靜態(tài)的，在編譯時(shí)刻便確定下來了對(duì)象模式：處理對(duì)象間的關(guān)系，這些關(guān)系在運(yùn)行時(shí)刻是可以變化的，更具動(dòng)態(tài)性幾乎所有模式都使用繼承機(jī)制所以“類模式”只指那些集中于處理類間關(guān)系的模式大部分模式都屬于對(duì)象模式的范疇設(shè)計(jì)模式的類型用來創(chuàng)建對(duì)象，抽象了實(shí)例化過程

單例（Singleton）：保證一個(gè)類有且僅有一個(gè)實(shí)例，提供一個(gè)全局訪問點(diǎn)工廠（Factory）：父類負(fù)責(zé)定義創(chuàng)建對(duì)象的公共接口，而子類則負(fù)責(zé)生成具體對(duì)象，將類的實(shí)例化操作延遲到子類中完成抽象工廠（AbstractFactory）：為一系列產(chǎn)品提供統(tǒng)一的創(chuàng)建接口。當(dāng)需要這個(gè)產(chǎn)品族的某一系列的時(shí)候，可以從抽象工廠中選出相應(yīng)的系列創(chuàng)建一個(gè)具體的工廠類創(chuàng)建型設(shè)計(jì)模式生成器（Builder）：將復(fù)雜對(duì)象創(chuàng)建與表示分離，同樣的創(chuàng)建過程可創(chuàng)建不同的表示。允許用戶通過指定復(fù)雜對(duì)象類型和內(nèi)容來創(chuàng)建對(duì)象，用戶不需要知道對(duì)象內(nèi)部的具體構(gòu)建細(xì)節(jié)原型（Prototype）：通過“復(fù)制”一個(gè)已經(jīng)存在的實(shí)例來返回新的實(shí)例（不新建實(shí)例）。被復(fù)制的實(shí)例就是“原型”，這個(gè)原型是可定制的。原型模式多用于創(chuàng)建復(fù)雜的或者耗時(shí)的實(shí)例，因?yàn)檫@種情況下，復(fù)制一個(gè)已經(jīng)存在的實(shí)例使程序運(yùn)行更高效；或者創(chuàng)建值相等，只是命名不一樣的同類數(shù)據(jù)

單例模式SingletonMethod

工廠模式FactoryMethod

抽象工廠模式AbstractFactoryMethod

建造者模式BuilderMethod

原型模式PrototypeMethod創(chuàng)建型設(shè)計(jì)模式單例(Singleton)模式的由來 系統(tǒng)中只能有一個(gè)窗口管理器、一個(gè)文件系統(tǒng)一個(gè)數(shù)字濾波器只能有一個(gè)A/D轉(zhuǎn)換器一個(gè)會(huì)計(jì)系統(tǒng)只能專用于一個(gè)公司一個(gè)全局變量使得一個(gè)對(duì)象可以被訪問，但它不能阻止防止實(shí)例化多個(gè)對(duì)象更好的辦法是，讓類自身負(fù)責(zé)保存它的唯一實(shí)例。這個(gè)類可以保證沒有其他實(shí)例可以被創(chuàng)建，并且它可以提供一個(gè)訪問該實(shí)例的方法單例模式的意圖和適用性意圖：保證一個(gè)類僅有一個(gè)實(shí)例并提供一個(gè)全局訪問點(diǎn)適用場(chǎng)合：當(dāng)類只能有一個(gè)實(shí)例，且用戶可以從一個(gè)眾所周知的訪問點(diǎn)訪問它時(shí)當(dāng)這個(gè)唯一實(shí)例是通過子類化可擴(kuò)展的，并且客戶應(yīng)該無需更改代碼就能使用一個(gè)擴(kuò)展實(shí)例時(shí)單例模式的結(jié)構(gòu)定義一個(gè)靜態(tài)Instance操作，允許客戶訪問它的唯一實(shí)例。Instance是一個(gè)類操作（一個(gè)靜態(tài)成員函數(shù)）Example只給司機(jī)一輛車publicclassCar{publicvoidrun(){System.out.prinln(“…”)}；}publicclassTest{publicstaticvoidmain(String[]args)Carc=newCar();c.run();}publicclassCar{privateCar(){}publicstaticCargetInstance(){returnnewCar()};publicvoidrun(){System.out.prinln(“…”)};}publicclassTest{publicstaticvoidmain(String[]args)

Carc=Car.getInstance();c.run();}一點(diǎn)改進(jìn)publicclassCar{

privatestaticCarcar=newCar();privateCar(){}publicstaticCargetInstance(){returncar;}publicvoidrun(){System.out.prinln(“…”)};}publicclassTest{publicstaticvoidmain(String[]args)Carc1=Car.getInstance();Carc2=Car.getInstance()’

if(c1==c2)System.out.println(“…”)；

c.run();}單例代碼示例延伸開來：多例MultitonpublicclassCar{privatestaticCarcar=newCar();

privatestaticList<Car>cars=newArrayList<Car>();privateCar(){publicstaticCargetInstance(){returncar;}}publicvoidrun(){System.out.prinln(“…”)};}publicclassTest{publicstaticvoidmain(String[]args)Carc1=Car.getInstance();Carc2=Car.getInstance()’if(c1==c2)System.out.println()；

c.run();}單例模式的效果分析對(duì)唯一實(shí)例受控訪問：因?yàn)镾ingleton類封裝唯一實(shí)例，所以它可以嚴(yán)格的控制客戶怎樣以及何時(shí)訪問它縮小命名空間：Singleton模式是對(duì)全局變量的一種改進(jìn)。它避免了那些存儲(chǔ)唯一實(shí)例的全局變量占用命名空間允許對(duì)操作和表示的精化：Singleton類可以有子類，而且用這個(gè)擴(kuò)展類的實(shí)例來配置一個(gè)應(yīng)用是很容易的?？梢杂盟枰念惖膶?shí)例在運(yùn)行時(shí)刻配置應(yīng)用工廠模式在面向?qū)ο缶幊讨?常用的方法是用new操作符構(gòu)造對(duì)象實(shí)例，但在有些情況下，new操作符直接生成對(duì)象會(huì)帶來一些問題（1）創(chuàng)建對(duì)象之前必須清楚所要?jiǎng)?chuàng)建對(duì)象的類信息，但個(gè)別情況下無法達(dá)到此要求，譬如打開一個(gè)視頻文件需要一個(gè)播放器對(duì)象，但是用戶可能不知道具體播放器叫什么名字，需要系統(tǒng)分派給這個(gè)視頻文件一個(gè)合適的播放器，這種情況下用new運(yùn)算符并不合適（2）許多類型對(duì)象的創(chuàng)造需要一系列步驟需要計(jì)算或取得對(duì)象的初始設(shè)置、需要選擇生成哪個(gè)子對(duì)象實(shí)例在生成需要對(duì)象之前必須先生成一些輔助功能對(duì)象在這些情況,新對(duì)象的建立就是一個(gè)“過程”，而不僅僅是一個(gè)操作。為了能方便地完成這些復(fù)雜的對(duì)象創(chuàng)建工作，可引入工廠模式工廠模式的結(jié)構(gòu)Product：定義工廠方法所創(chuàng)建對(duì)象的接口ConcreteProduct(A,B)：實(shí)現(xiàn)Product接口Factory：聲明工廠方法，返回一個(gè)Product類型對(duì)象。一個(gè)日志管理器：設(shè)計(jì)日志記錄類，支持記錄的方法有FileLogEventLog實(shí)例1//

LogFactory類

public

abstract

class

LogFactory

{

public

abstract

Log

Create();

}//

FileFactory類

public

class

FileFactory:LogFactory

{

public

override

FileLog

Create()

{

return

new

FileLog();

}

}//

EventFactory類

public

class

EventFactory:LogFactory

{

public

override

EventLog

Create()

{

return

new

EventLog();

}

}public

class

App

{

public

static

void

Main(string[]

args)

{

LogFactory

factory

=

new

EventFactory();

Log

log

=

factory.Create();

log.Write();

}

}PublicinterfaceMoveable{publicvoidrun();}PublicclassPlaneimplementsMoveable{@Overridepublicvoidrun(){…};}PublicclassCarimplementsMoveable{@Overridepublicvoidrun(){…};}PublicabstractclassVehicleFactory{abstractMoveablecreate();}PublicclassPlaneFactoryextendsVehicleFactory{publicMoveablecreate(){returnnewPlane();}}PublicclassCarFactoryextendsVehicleFactory{publicMoveablecreate(){returnnewCar();}}PublicclassTest{publicstaticvoidmain(String[]args){VehicleFactoryf=newPlaneFactory();//theonlychangehappenshere!Moveablem=f.create();m.run();}}實(shí)例2：任意定制交通工具的類型和生產(chǎn)過程抽象工廠模式的由來面臨“一系列相互依賴對(duì)象”的創(chuàng)建工作，由于需求變化，這“一系列相互依賴的對(duì)象”也要改變，如何應(yīng)對(duì)這種變化呢？實(shí)例：Windows桌面主題，當(dāng)更換一個(gè)桌面主題的時(shí)候，系統(tǒng)的開始按鈕、任務(wù)欄、菜單欄、工具欄等都變了，而且是一起變的，他們的色調(diào)都很一致，類似這樣的問題如何解決呢？應(yīng)用抽象工廠模式，是一種有效的解決途徑抽象工廠模式的意圖意圖：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無需指定他們具體的類適用場(chǎng)合一個(gè)系統(tǒng)獨(dú)立于其產(chǎn)品創(chuàng)建、組合和表示時(shí)一個(gè)系統(tǒng)由多個(gè)產(chǎn)品系列中的一個(gè)來配置時(shí)強(qiáng)調(diào)一系列相關(guān)產(chǎn)品對(duì)象的設(shè)計(jì)以便進(jìn)行聯(lián)合時(shí)提供一個(gè)產(chǎn)品類庫(kù)，只想顯示其接口而非實(shí)現(xiàn)時(shí)抽象工廠模式的結(jié)構(gòu)AbstractFactory：聲明創(chuàng)建抽象產(chǎn)品對(duì)象的操作接口ConcreteFactory：實(shí)現(xiàn)創(chuàng)建具體對(duì)象的操作AbstractProduct：為一類產(chǎn)品對(duì)象聲明一個(gè)接口ConcreteProduct：定義一個(gè)被具體工廠創(chuàng)建的產(chǎn)品對(duì)象實(shí)例1：系列產(chǎn)品替換publicclassCarextendsVehicle{}publicclassAK47extendsWeapon{}publicclassAppleextendsFood{publicVoidprintName(return…);}publicabstractclassVehicle{publicabstractvoidrun();}publicabstractclassWeapon{publicabstractvoidshoot();}publicabstractclassFood{publicabstractvoidprintName();}publicabstractclassAbstractFactory{publicabstractVehiclecreateVehicle();publicabstractWeaponcreateWeapon();publicabstractFoodcreateFood();}publicclassDefaultFactoryextendsAbstractFactory{publicVehiclecreateVehicle(){returnnewCar();}publicWeaponcreateWeapon(){returnnewAK47();};publicFoodcreateFood(){returnnewApple();};}publicclassMagicFactoryextendsAbstractFactory{publicVehiclecreateVehicle(){returnnewBroom();}publicWeaponcreateWeapon(){returnnewMagicStick();};publicFoodcreateFood(){returnnewMushroom();};}publicclassTest{AbstactFactoryf=newDefaultFactory();//onlychangesheretoMagicFactory();Vehiclev=f.createVehicle();c.run();Weaponw=f.createWeapon();w.shoot();Fooda=f.createFood();a.printName();}花園有三種風(fēng)格：典雅型、實(shí)用型和懶人型花園中有3個(gè)位置需要種植植物：花臺(tái)、墻角和花園中心實(shí)例2：花園布置（作業(yè)）風(fēng)格/位置花臺(tái)中心墻角典雅型郁金香榕樹蘭草實(shí)用型葡萄石榴絲瓜懶人型月季茶花竹子工廠模式是一種極端情況下的抽象工廠模式，而抽象工廠模式可以看成是工廠模式的一種推廣工廠模式的特點(diǎn)一個(gè)抽象產(chǎn)品類，可以派生出多個(gè)具體產(chǎn)品類一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類每個(gè)具體工廠類只能創(chuàng)建一個(gè)具體的長(zhǎng)品類實(shí)例抽象工廠模式的特點(diǎn)多個(gè)抽象產(chǎn)品類，每個(gè)抽象產(chǎn)品類可以派生出多個(gè)具體產(chǎn)品類一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類每個(gè)具體工廠類可以創(chuàng)建多個(gè)具體產(chǎn)品類的實(shí)例抽象工廠模式與工廠模式的區(qū)別提供一個(gè)接口，用于創(chuàng)建相關(guān)和依賴對(duì)象的家族，而不需要明確指定具體類。抽象工廠允許客戶使用抽象接口來創(chuàng)建一組相關(guān)產(chǎn)品，而不需要關(guān)心具體實(shí)際產(chǎn)出的產(chǎn)品是什么總結(jié)所有工廠都是用來封裝對(duì)象的創(chuàng)建簡(jiǎn)單工廠，可以把客戶程序從具體類解耦工廠方法使用繼承，把對(duì)象創(chuàng)建委托給子類，子類實(shí)現(xiàn)工廠方法來創(chuàng)建對(duì)象抽象工廠使用對(duì)象組合：對(duì)象的創(chuàng)建被實(shí)現(xiàn)在工廠接口所暴露出來的方法中所有工廠模式都是通過減少應(yīng)用程序與具體類之間的依賴關(guān)系促進(jìn)松耦合工廠方法允許類將實(shí)例化延遲到子類進(jìn)行抽象工廠創(chuàng)建相關(guān)的家族，而不需要依賴他們的具體類工廠幫助我們針對(duì)抽象編程，而不是針對(duì)具體類編程抽象工廠模式與工廠模式的區(qū)別建造者（Builder）模式的由來在軟件系統(tǒng)中，有時(shí)面臨著“一個(gè)復(fù)雜對(duì)象”的創(chuàng)建工作，該復(fù)雜對(duì)象通常由各個(gè)部分的子對(duì)象用一定的算法構(gòu)成這個(gè)復(fù)雜對(duì)象的各個(gè)部分經(jīng)常面臨著劇烈變化，但是將它們組合在一起的算法卻相對(duì)穩(wěn)定如何應(yīng)對(duì)這種變化？如何提供一種“封裝機(jī)制”來隔離出“復(fù)雜對(duì)象的各個(gè)部分”的變化，從而保持系統(tǒng)中的“穩(wěn)定構(gòu)建算法”不隨著需求改變而改變？建造者模式的意圖和適用性意圖：將一個(gè)復(fù)雜的構(gòu)建與其表示相分離，使同樣的構(gòu)建過程可以創(chuàng)建不同的表示適用場(chǎng)合需要生成的產(chǎn)品有復(fù)雜的內(nèi)部結(jié)構(gòu)創(chuàng)建復(fù)雜對(duì)象的算法穩(wěn)定，或建造者模式可以強(qiáng)迫生成一定的順序當(dāng)構(gòu)造過程允許被構(gòu)造的對(duì)象有不同的表示時(shí)Builder：為創(chuàng)建一個(gè)Product對(duì)象的各個(gè)部件制定的抽象接口ConcreteBuilder：實(shí)現(xiàn)Builder接口來構(gòu)造和裝配產(chǎn)品各個(gè)部件，提供一個(gè)檢索產(chǎn)品的接口Director：構(gòu)造一個(gè)使用Builder接口的對(duì)象Product：表示被構(gòu)造的復(fù)雜對(duì)象建造者模式的結(jié)構(gòu)建造者模式分析 優(yōu)點(diǎn)：使得產(chǎn)品的內(nèi)部表象可獨(dú)立變化客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)每一個(gè)Builder都相對(duì)獨(dú)立，而與其它Builder無關(guān)可對(duì)構(gòu)造過程更加精細(xì)控制將構(gòu)建代碼和表示代碼分開缺點(diǎn)：難于“分步驟構(gòu)建算法”制造產(chǎn)品對(duì)象Builder模式與AbstractFactory模式的區(qū)別Builder返回完整的一個(gè)產(chǎn)品，而AbstractFactory返回一系列有關(guān)系的產(chǎn)品在AbstractFactory模式中，客戶采用AbstractFactory生成自己要用的對(duì)象，而在建造者模式中，客戶指導(dǎo)Builder類如何去生成對(duì)象，或是如何和成一些類來構(gòu)成建造類，側(cè)重于一步步構(gòu)造一個(gè)復(fù)雜對(duì)象，然后將結(jié)果返回。房屋由五個(gè)部分組成：地板、墻壁、窗戶、門和天花板構(gòu)建房屋的步驟固定，而具體組件（門、窗等）易變采用建造者模式分離易變組件和穩(wěn)定的構(gòu)建過程實(shí)例1：設(shè)計(jì)游戲場(chǎng)景中的房屋publicabstractclassHouse//定義一個(gè)房屋抽象類{}publicabstractclassBuilder

//這一部分是易變的

{

publicabstractvoidBuildFloor();//地板publicabstractvoidBuildDoor();//門

publicabstractvoidBuildWindows();//窗戶publicabstractvoidBuildWall();//墻壁publicabstractvoidBuildHouseCeiling()//天花板publicabstractHouseGetHouse();}publicabstractclassGameManager

{

publicstaticHouseCreateHouse(Builderbuilder){builder.BuildFloor();builder.BuildDoor();builder.Buildwall();builder.BuildWindows();builder.BuildHouseCeiling();returnbuilder.GetHouse();}}publicclassRomanHouseBuilder:Builder{publicoverridevoidBuildDoor(){}publicoverridevoidBuildFloor(){}

publicoverridevoidBuildWindows(){}publicoverridevoidBuildWall(){}publicoverridevoidBuildHouseCeiling(){}publicoverrideHouseGetHouse(){}}classApp{publicstaticvoidmain(){Househouse=GameManager.CreateHouse(newRomanHouseBuilder());}}實(shí)例2：造車（作業(yè)）原型（Prototype）模式在軟件系統(tǒng)中，客戶希望創(chuàng)建一個(gè)類對(duì)象（產(chǎn)品）時(shí)，可能有三種情況：知道產(chǎn)品具體型號(hào)(使用new運(yùn)算符創(chuàng)建)不知道型號(hào)，知道特定的需求(使用工廠模式)不知道需求，但想要一個(gè)和已知對(duì)象相同的對(duì)象-使用原型模式意圖：用原型實(shí)例指定創(chuàng)建對(duì)象種類，并且通過拷貝這些原型創(chuàng)建新的對(duì)象適用性：當(dāng)一個(gè)系統(tǒng)獨(dú)立于其產(chǎn)品創(chuàng)建、構(gòu)成和表示時(shí)當(dāng)要實(shí)例化的類在運(yùn)行時(shí)刻指定時(shí)為了避免創(chuàng)建一個(gè)與產(chǎn)品類層次平行的工廠類層次時(shí)原型模式的結(jié)構(gòu)Client：客戶端類向原型管理器提出創(chuàng)建對(duì)象請(qǐng)求抽象原型：它是對(duì)各種具體原型的抽象，通常由一個(gè)接口或抽象類實(shí)現(xiàn)具體原型：被復(fù)制的對(duì)象。此角色需要實(shí)現(xiàn)抽象的原型角色所要求的接口原型管理器：創(chuàng)建具體原型類的對(duì)象，記錄每一個(gè)被創(chuàng)建的對(duì)象用戶單擊調(diào)色板上任一個(gè)方塊，將會(huì)返回一個(gè)對(duì)應(yīng)的顏色的實(shí)例利用OO的思想，把每一種顏色作為一個(gè)對(duì)象，并為它們抽象出一個(gè)公用的父類實(shí)例1：開發(fā)調(diào)色板使用原型模式開發(fā)調(diào)色板的結(jié)構(gòu)圖優(yōu)點(diǎn)：（1）對(duì)客戶隱藏具體產(chǎn)品類，減少了客戶知道名字的數(shù)目（2）允許客戶只通過注冊(cè)原型實(shí)例就可以將一個(gè)具體產(chǎn)品類并入系統(tǒng)中，客戶可以在運(yùn)行時(shí)刻建立和刪除原型（3）具有給一個(gè)應(yīng)用軟件動(dòng)態(tài)加載新功能的能力。由于其獨(dú)立性較高，可以很容易動(dòng)態(tài)加載新功能而不影響老系統(tǒng)（4）產(chǎn)品類可有任意結(jié)構(gòu)缺點(diǎn)：每個(gè)類必須配備一個(gè)克隆方法原型模式的應(yīng)用效果分析單件模式：一個(gè)類只有一個(gè)實(shí)例，并提供全局訪問點(diǎn)工廠模式：定義一個(gè)創(chuàng)建對(duì)象的接口，由子類決定要實(shí)例化的具體類，工廠方法讓類把實(shí)例化推遲到子類抽象工廠模式：提供一個(gè)接口，用于創(chuàng)建相關(guān)或依賴對(duì)象的家族，而不需要明確指定具體類建造者模式：封裝一個(gè)產(chǎn)品（復(fù)雜對(duì)象）的構(gòu)造過程，并允許按照步驟構(gòu)造，向客戶隱藏了產(chǎn)品的內(nèi)部表現(xiàn)原型模式：當(dāng)創(chuàng)建給定類實(shí)例的過程很昂貴或很復(fù)雜時(shí)，使用原型模式，向客戶隱藏制造新實(shí)例的復(fù)雜性創(chuàng)建型設(shè)計(jì)模式總結(jié)關(guān)注類和對(duì)象的結(jié)構(gòu)，采用繼承機(jī)制來組合接口（類結(jié)構(gòu)型模式），或通過組合一些對(duì)象來實(shí)現(xiàn)新的功能（對(duì)象結(jié)構(gòu)型模式）組合（Composite）：定義一個(gè)接口，用于單一對(duì)象，或用于多個(gè)單一對(duì)象組成的對(duì)象組裝飾（Decorator）：給對(duì)象動(dòng)態(tài)添加額外的職責(zé)，好比加上裝飾物，完善其功能代理（Proxy）：有些對(duì)象由于跨網(wǎng)絡(luò)或其他障礙，而不能或不想直接訪問另一個(gè)對(duì)象，這時(shí)候可以在客戶程序和目標(biāo)對(duì)象之間增加一層中間層，讓代理對(duì)象來代替目標(biāo)對(duì)象打點(diǎn)一切結(jié)構(gòu)型設(shè)計(jì)模式享元（Flyweight）：Flyweight是一個(gè)共享對(duì)象，它可以同時(shí)在不同上下文使用外觀（Facade）：為子系統(tǒng)提供了一個(gè)更高層次、更簡(jiǎn)單的接口，從而降低子系統(tǒng)復(fù)雜度，更易于使用和管理。外觀承擔(dān)了子系統(tǒng)中類交互的責(zé)任橋梁（Bridge）：將問題的抽象和實(shí)現(xiàn)分離開來實(shí)現(xiàn)，通過用聚合代替繼承來解決子類爆炸性增長(zhǎng)的問題適配器(Adapter)：將一個(gè)類的接口適配成用戶所期待的接口。一個(gè)適配器允許因?yàn)榻涌诓患嫒荻荒茉谝黄鸸ぷ鞯念惞ぷ髟谝黄?，做法是將類自己的接口包裝在一個(gè)已存在的類中適配器模式外觀模式裝飾模式橋接模式享元模式代理模式組合模式結(jié)構(gòu)型模式適配器模式的由來一個(gè)team要為外界提供S類服務(wù)，但team里面沒有能夠完成此項(xiàng)任務(wù)的member，只有team外的A可以完成這項(xiàng)服務(wù)。為保證對(duì)外服務(wù)類別的一致性（提供S服務(wù)）將A招到team內(nèi)，負(fù)責(zé)提供S類服務(wù)A不準(zhǔn)備接受招安，可安排B去完成這項(xiàng)任務(wù)，并讓B做好A的工作，讓B工作的時(shí)候向A請(qǐng)教，此時(shí)，B是一個(gè)復(fù)合體（提供S服務(wù)，是A的繼承弟子）將一個(gè)類的接口，轉(zhuǎn)換成客戶期望的另一個(gè)接口，適配器讓原本接口不兼容的類可以一起工作適配器模式使用過程客戶通過目標(biāo)接口調(diào)用適配器的方法對(duì)適配器發(fā)出請(qǐng)求適配器使用被適配者接口把請(qǐng)求轉(zhuǎn)換成被適配者的一個(gè)或者多個(gè)調(diào)用接口客戶接收到調(diào)用的結(jié)果，但并未察覺這一切是適配器在起轉(zhuǎn)換作用適配器模式的意圖和適用性意圖：將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口，使得原本由于接口不兼容而不能一起工作的類可以一起工作適用場(chǎng)合：使用一個(gè)已經(jīng)存在的類，而它的接口不符合要求創(chuàng)建一個(gè)可以復(fù)用的類，該類可以與其他不相關(guān)的類或不可預(yù)見的類（即那些接口可能不一定兼容的類）協(xié)同工作使用一些已經(jīng)存在的子類，但不可能通過子類化以匹配各自接口。對(duì)象適配器可以適配它的父類接口適配器模式分為類適配器和對(duì)象適配器類適配器用一個(gè)具體的Adapter類對(duì)Adaptee和Target進(jìn)行匹配，Adapter類多重繼承Adaptee和Target類Adapter可重定義Adaptee的部分行為，因?yàn)锳dapter是Adaptee的一個(gè)子類代碼示例//Target：定義Client使用的與特定領(lǐng)域相關(guān)的接口publicinterfaceTarget{voidrequest();}//Adaptee:現(xiàn)在需要適配的已經(jīng)存在的接口publicclassAdaptee{publicvoidspecificRequest(){}}//Adapter:對(duì)Adaptee的接口與Target接口進(jìn)行適配publicclassAdapterextendsAdapteeimplementsTarget{publicvoidrequest(){super.specificRequest();}}對(duì)象適配器允許一個(gè)Adapter與多個(gè)Adaptee同時(shí)工作，即Adaptee本身以及它的所有子類（如果有子類的話）同時(shí)工作。Adapter可以一次給所有的Adaptee添加功能使用組合，不僅可以適配某個(gè)類，也可以適配該類的任何子類代碼示例//Target：定義Client使用的與特定領(lǐng)域相關(guān)的接口publicinterfaceTarget{voidrequest();}//Adaptee:現(xiàn)在需要適配的已經(jīng)存在的接口publicclassAdaptee{publicvoidspecificRequest(){}}//Adapter:對(duì)Adaptee的接口與Target接口進(jìn)行適配publicclassAdapterimplementsTarget{publicAdapter(Adapteeadaptee){super();this.adaptee=adaptee;}publicvoidrequest(){adaptee.specificRequest();}privateAdapteeadaptee;}著力解決的是類實(shí)體之間的通訊關(guān)系，希望以面向?qū)ο蟮姆绞矫枋鲆粋€(gè)控制流程模版（Template）：定義了一個(gè)算法步驟，并允許子類為一個(gè)或多個(gè)步驟提供實(shí)現(xiàn)。子類在不改變算法架構(gòu)的情況下，可重新定義算法中某些步驟觀察者（Observer）：定義了對(duì)象之間一對(duì)多的依賴，當(dāng)這個(gè)對(duì)象的狀態(tài)發(fā)生改變的時(shí)候，多個(gè)對(duì)象會(huì)接受到通知，有機(jī)會(huì)做出反饋迭代（Iterator）：提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素,而又不需暴露該對(duì)象的內(nèi)部表示行為型設(shè)計(jì)模式責(zé)任鏈（ChainofResponsibility）：很多對(duì)象由每一個(gè)對(duì)象對(duì)其下一個(gè)對(duì)象的引用而連接起來形成一條鏈。請(qǐng)求在這個(gè)鏈上傳遞，直到鏈上的某一個(gè)對(duì)象決定處理此請(qǐng)求。