摘要：抽象工廠(chǎng)模式是為了處理對(duì)象具有等級(jí)結(jié)構(gòu)以及對(duì)象族的問(wèn)題。單例設(shè)計(jì)模式單例模式確保某一個(gè)類(lèi)只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例，這個(gè)類(lèi)成為單例類(lèi)。

導(dǎo)語(yǔ)：設(shè)計(jì)模式是無(wú)數(shù)碼農(nóng)前人在實(shí)際的生產(chǎn)項(xiàng)目中經(jīng)過(guò)不斷的踩坑、爬坑、修坑的經(jīng)歷總結(jié)出來(lái)的經(jīng)驗(yàn)教訓(xùn)，經(jīng)過(guò)抽象之后表達(dá)成的概念。能夠幫助后來(lái)的設(shè)計(jì)者避免重復(fù)同樣的錯(cuò)誤或者彎路。我也抽空整理了一下設(shè)計(jì)模式，用自己的話(huà)總結(jié)了一下，自認(rèn)為通俗易懂。覺(jué)得有用的朋友可以收藏一下。

簡(jiǎn)單工廠(chǎng)模式：

包括三種角色，抽象產(chǎn)品、具體產(chǎn)品和工廠(chǎng)角色。其中在工廠(chǎng)直接完成對(duì)具體產(chǎn)品的創(chuàng)建。工廠(chǎng)模式的好處是需要?jiǎng)?chuàng)建對(duì)象的時(shí)候只需要輸入一個(gè)正確的參數(shù)就可以獲得所需要的對(duì)象，而無(wú)需知道其創(chuàng)建細(xì)節(jié)，這種模式將對(duì)象的創(chuàng)建和對(duì)象業(yè)務(wù)的處理分離，降低系統(tǒng)的耦合度，使得兩者修改起來(lái)都相對(duì)容易。

工廠(chǎng)方法模式：

該模式包括四種角色，抽象工廠(chǎng)、具體工廠(chǎng)、抽象產(chǎn)品和具體產(chǎn)品角色。與簡(jiǎn)單工廠(chǎng)模式相比，抽象工廠(chǎng)負(fù)責(zé)定義創(chuàng)建產(chǎn)品對(duì)象的公共接口，而工廠(chǎng)子類(lèi)則負(fù)責(zé)生產(chǎn)具體的產(chǎn)品對(duì)象。這樣可以將產(chǎn)品類(lèi)的實(shí)例化操作延遲到工廠(chǎng)子類(lèi)中完成。這樣，當(dāng)需要生成一個(gè)具體產(chǎn)品對(duì)象時(shí)，首先要生成該對(duì)象的產(chǎn)品工廠(chǎng)。這樣的好處是可擴(kuò)展性很好。

抽象工廠(chǎng)模式：

在工廠(chǎng)方法模式中，具體工廠(chǎng)負(fù)責(zé)生產(chǎn)具體的產(chǎn)品，每一個(gè)具體工廠(chǎng)對(duì)應(yīng)一種具體產(chǎn)品，工廠(chǎng)方法也具有唯一性，一般情況下一個(gè)具體工廠(chǎng)中只有一工廠(chǎng)方法或者一組重載的工廠(chǎng)方法，但是有的時(shí)候我們需要一個(gè)工廠(chǎng)可以提供多個(gè)產(chǎn)品對(duì)象，而不是單一的產(chǎn)品對(duì)象。抽象工廠(chǎng)模式是為了處理對(duì)象具有等級(jí)結(jié)構(gòu)以及對(duì)象族的問(wèn)題。對(duì)象的等級(jí)結(jié)構(gòu)即是對(duì)象的繼承結(jié)構(gòu)，比如電視機(jī)是一個(gè)抽象父類(lèi)，其子類(lèi)有海爾電視機(jī)、海信電視機(jī)、TCL電視機(jī)等。對(duì)象族：是指同一個(gè)工廠(chǎng)生產(chǎn)的、位于不同對(duì)象等級(jí)結(jié)構(gòu)中的一組對(duì)象。如海爾生產(chǎn)的海爾電視機(jī)、海爾電冰箱，這兩個(gè)都位于海爾電器的產(chǎn)品族中，其中海爾電視機(jī)位于電視機(jī)等級(jí)結(jié)構(gòu)中，海爾電冰箱位于電冰箱等級(jí)結(jié)構(gòu)中。

抽象工廠(chǎng)模式包括抽象工廠(chǎng)、具體工廠(chǎng)、抽象產(chǎn)品、具體產(chǎn)品4中角色。每一個(gè)具體工廠(chǎng)代表了一個(gè)對(duì)象族，都提供了多個(gè)工廠(chǎng)方法用于生產(chǎn)多種不同類(lèi)型的產(chǎn)品，這些產(chǎn)品構(gòu)成了一個(gè)對(duì)象族。

使用抽象工廠(chǎng)模式創(chuàng)建對(duì)象的時(shí)候，首先創(chuàng)建對(duì)應(yīng)該對(duì)象族的工廠(chǎng)，然后調(diào)用該工廠(chǎng)中創(chuàng)建該對(duì)象的方法。

建造者模式：

建造者模式講一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得童顏的構(gòu)建過(guò)程可以創(chuàng)建不同的表示，它允許用戶(hù)只通過(guò)指定復(fù)雜對(duì)象的類(lèi)型和內(nèi)容就可以創(chuàng)建它們，而不需要參與內(nèi)部的具體構(gòu)建細(xì)節(jié)。建造者模式包括4種角色：指揮者角色、抽象構(gòu)造者角色、具體構(gòu)造者角色以及產(chǎn)品角色。具體構(gòu)造者負(fù)責(zé)生成具體的對(duì)象、指揮者一方面隔離了客戶(hù)和生產(chǎn)過(guò)程，另一方面負(fù)責(zé)監(jiān)控產(chǎn)品的生成過(guò)程，比如復(fù)雜對(duì)象的各個(gè)部分是以怎樣的順序生成等。指揮者針對(duì)抽象建造者編程，客戶(hù)端只需要知道具體構(gòu)造者的類(lèi)型，即可通過(guò)指揮者類(lèi)調(diào)用構(gòu)造者的相關(guān)方法，返回一個(gè)完整的產(chǎn)品對(duì)象。

距離說(shuō)明，去KFC點(diǎn)餐的過(guò)程。一份套餐需要三個(gè)對(duì)象組成，即：可樂(lè)、漢堡和薯?xiàng)l。生產(chǎn)這些對(duì)象的師傅即為具體建造者，服務(wù)員為指揮者，套餐為產(chǎn)品角色。顯然，師傅在后臺(tái)如何生產(chǎn)這些產(chǎn)品我們并不知道，而是有服務(wù)員把這些對(duì)象構(gòu)造成一份套餐。

原型模式：

原型設(shè)計(jì)模式：如果一些對(duì)象的創(chuàng)建構(gòu)成比較復(fù)雜，而且有時(shí)候需要頻繁的創(chuàng)建，原型模式通過(guò)給出一個(gè)原型對(duì)象來(lái)指明索要?jiǎng)?chuàng)建的對(duì)象的類(lèi)型，然后用復(fù)制這個(gè)原型的辦法創(chuàng)建出跟多同類(lèi)型的對(duì)象。淺拷貝、深拷貝。

原型模式的適用場(chǎng)景：

Struts2中為了保證線(xiàn)程安全性，Action對(duì)象的創(chuàng)建使用了原型模式，訪(fǎng)問(wèn)一個(gè)已經(jīng)存在的Action時(shí)將通過(guò)克隆的方式創(chuàng)建出一個(gè)新的對(duì)象。從而保證其中定義的變量無(wú)須進(jìn)行加鎖實(shí)現(xiàn)同步，每一個(gè)Action中都有自己的成員變量，避免Struts1因使用單例模式而導(dǎo)致的并發(fā)和同步問(wèn)題。

Spring中，用戶(hù)也可以采用原型來(lái)創(chuàng)建新的bean實(shí)例，從而實(shí)現(xiàn)每次獲取的是通過(guò)克隆生成的新實(shí)例，對(duì)其進(jìn)行修改時(shí)對(duì)原有實(shí)例對(duì)象不造成任何影響。

單例設(shè)計(jì)模式：

單例模式確保某一個(gè)類(lèi)只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例，這個(gè)類(lèi)成為單例類(lèi)。單例模式的實(shí)現(xiàn)一般是構(gòu)造函數(shù)私有化、自行實(shí)例化一個(gè)實(shí)例并提供靜態(tài)函數(shù)供整個(gè)系統(tǒng)訪(fǎng)問(wèn)這個(gè)實(shí)例。其應(yīng)用場(chǎng)景包括：java.lang.Runtimr類(lèi)、線(xiàn)程池ThreadPool類(lèi)中。

適配器設(shè)計(jì)模式：

適配器模式是將一個(gè)類(lèi)的接口轉(zhuǎn)換成客戶(hù)希望的另一個(gè)接口，使得原本由于接口不兼容而不能一起工作的類(lèi)可以一起工作。包括四個(gè)角色：客戶(hù)端、目標(biāo)接口、適配器、適配者。

適用場(chǎng)景：已經(jīng)存在的類(lèi)的接口具有實(shí)用的功能但是不符合我們的要求。比如我們?cè)诔绦蛑心硞€(gè)類(lèi)C最終面對(duì)的是A接口或抽象類(lèi)，因此類(lèi)C只能使用A的子類(lèi)或者實(shí)現(xiàn)類(lèi)。假設(shè)我們有B類(lèi)含有特殊的操作或功能，現(xiàn)在我們想在自己的系統(tǒng)中使用它，我們可以將其轉(zhuǎn)化成符合我們的標(biāo)準(zhǔn)的類(lèi)。這樣，C類(lèi)就可以在透明的情況下任意的選擇使用C類(lèi)的子類(lèi)或者具有特殊功能的B類(lèi)。根據(jù)轉(zhuǎn)化的方式可以分為類(lèi)適配器和對(duì)象適配器。

類(lèi)適配器：自定義適配器，該適配器繼承自B，并且實(shí)現(xiàn)了A，這樣根據(jù)多態(tài)性，類(lèi)C就可以很對(duì)該適配器編程。

對(duì)象適配器：適配器采用組合的形式，不再繼承B，而是關(guān)聯(lián)一個(gè)B對(duì)象。

適配器模式的應(yīng)用場(chǎng)景：Hibernate自帶的日志系統(tǒng)是sel4j，自帶了一個(gè)jar包，slf4j-api-1.5.8.jar。打開(kāi)這個(gè)jar包我們發(fā)現(xiàn)只是定義了一些接口，沒(méi)有具體實(shí)現(xiàn)。如果想用slf4j日志系統(tǒng)，需要引入slf4j-nop-1.5.8.jar實(shí)現(xiàn)jar包。但是這個(gè)日志系統(tǒng)沒(méi)有l(wèi)og4j使用的廣泛，因此Hibernate提供了一個(gè)jar包：slf4j-log4j12-1.5.8.jar，然后我們?cè)僖雔og4j.jar，這樣通過(guò)slf4j-log4j12-1.5.8.jar的適配作用，我們就可以通過(guò)調(diào)用slf4j的接口使用log4j的日志功能。這是Hibernate中典型的適配器模式設(shè)計(jì)。

橋接模式：

橋接模式的設(shè)計(jì)思想是讓抽象部分與他的實(shí)現(xiàn)部分分離，使他們可以獨(dú)立的變化。它主要應(yīng)對(duì)的是：由于實(shí)際的需要，某個(gè)類(lèi)具有兩個(gè)或兩個(gè)以上的維度變化，如果只是用繼承將無(wú)法實(shí)現(xiàn)這種需要，或者使得設(shè)計(jì)變得相當(dāng)臃腫。

比如說(shuō)現(xiàn)在我要設(shè)計(jì)一個(gè)通用的日志記錄工具。它支持?jǐn)?shù)據(jù)庫(kù)記錄databaseLog和文本文件記錄FileLog兩種方式，同時(shí)既可以運(yùn)行在.net平臺(tái)和java平臺(tái)。按照繼承的思路，我們首先抽象出一個(gè)Log基類(lèi)，各種不同的日志記錄方式都要繼承這個(gè)類(lèi)。在這里這兩種日志格式都要繼承Log類(lèi)。另外考慮到不同平臺(tái)的日志記錄，對(duì)于操作數(shù)據(jù)庫(kù)、寫(xiě)入文本文件鎖調(diào)用的方式可能是不一樣的，因此需要提供各種不同平臺(tái)上的實(shí)現(xiàn)，對(duì)上面的類(lèi)因此得到四種繼承方式。但是，這種格式使得設(shè)計(jì)變得相當(dāng)臃腫。如果我有5中日志格式、5中運(yùn)行平臺(tái)，則需要25中繼承方式。我們可以看到這種臃腫的繼承關(guān)系造成的根源在于引起Log變化的原因有兩個(gè)，即日志記錄方式的變化和日志記錄平臺(tái)的變化?，F(xiàn)在我們要解耦這兩個(gè)方向的變化，把他們之前強(qiáng)耦合的繼承關(guān)系便為弱耦合的關(guān)聯(lián)關(guān)系。這就是橋接模式。

我們可以把記錄記錄格式和日記記錄在不同平臺(tái)的實(shí)現(xiàn)分別當(dāng)作兩個(gè)獨(dú)立的部分來(lái)對(duì)待，對(duì)于日志記錄方式，類(lèi)結(jié)構(gòu)仍是databaseLog類(lèi)和FileLog兩個(gè)類(lèi)繼承Log類(lèi)。對(duì)于日志記錄平臺(tái)，引入另外一個(gè)抽象類(lèi)，ImpLog，它是日志記錄在不同平臺(tái)上的實(shí)現(xiàn)的基類(lèi)。這個(gè)時(shí)候，對(duì)于日志記錄方式和不同的運(yùn)行平臺(tái)這兩個(gè)類(lèi)可以獨(dú)立的變化了。我們要做的就是把這兩個(gè)部分連接起來(lái)。在這里使用對(duì)象組合的方式，即在Log類(lèi)中關(guān)聯(lián)一個(gè)ImpLog對(duì)象。可以看到，通過(guò)對(duì)象組合的方式，Bridge模式把兩個(gè)角色之間的繼承關(guān)系改為了耦合的關(guān)系，從而使這兩者可以從容自若的各自獨(dú)立的變化，這也是Bridge模式的本意。

1、JDBC驅(qū)動(dòng)程序也是橋接模式的應(yīng)用之一。使用JDBC驅(qū)動(dòng)程序的應(yīng)用系統(tǒng)就是抽象角色，而所使用的數(shù)據(jù)庫(kù)是實(shí)現(xiàn)角色。一個(gè)JDBC驅(qū)動(dòng)程序可以動(dòng)態(tài)地將一個(gè)特定類(lèi)型的數(shù)據(jù)庫(kù)與一個(gè)Java應(yīng)用程序綁定在一起，從而實(shí)現(xiàn)抽象角色與實(shí)現(xiàn)角色的動(dòng)態(tài)耦合。

組合模式：

組合模式描述了如何將容器對(duì)象和葉子對(duì)象進(jìn)行遞歸組合，使得用戶(hù)在使用時(shí)無(wú)須對(duì)它們進(jìn)行區(qū)分，可以一致的對(duì)待容器對(duì)象和葉子對(duì)象。組合多個(gè)對(duì)象形成鼠樹(shù)形結(jié)構(gòu)以表示整體部分的層次結(jié)構(gòu)。組合模式對(duì)但對(duì)象（即葉子對(duì)象）和組合對(duì)象（容器對(duì)象）的使用具有一致性。組合模式包括抽象組件、葉子組件和容器組件以及客戶(hù)類(lèi)。

組合模式的關(guān)鍵是定義了一個(gè)抽象類(lèi)，他既可以代表葉子，也可以代表容器，而客戶(hù)端針對(duì)該抽象組件進(jìn)行編程，無(wú)須知道它到底表示的是葉子還是容器，可以對(duì)其進(jìn)行統(tǒng)一的處理。同時(shí)容器對(duì)象與抽象構(gòu)件之間還存在一個(gè)聚合關(guān)聯(lián)關(guān)系，在容器對(duì)象中既可以包含葉子也可以包含容器。比如文件系統(tǒng)的UML圖。

實(shí)現(xiàn)組合模式有兩種思路（1）在抽象組件中定義葉子節(jié)點(diǎn)和容器節(jié)點(diǎn)公共的方法，比如定義一個(gè)表示文件系統(tǒng)節(jié)點(diǎn)的抽象組件，可以只定義顯示名稱(chēng)的方法，這樣在容器組件中擴(kuò)展抽象組件的方法。（2）在抽象組件中明確定義容器節(jié)點(diǎn)所有的方法，這些方法有些肯定是葉子節(jié)點(diǎn)不能使用的，比如文件系統(tǒng)中葉子節(jié)點(diǎn)不會(huì)有remove刪除一個(gè)文件的方法。這時(shí)候抽象組件一般是一個(gè)抽象類(lèi)，抽象類(lèi)中對(duì)這些方法做了一般的處理，而在容器節(jié)點(diǎn)中根據(jù)功能進(jìn)行相應(yīng)的覆蓋。Java中XML文檔解析以及Java的AWT/SWing均用到了組合模式。

裝飾設(shè)計(jì)模式：

當(dāng)想要對(duì)已有的對(duì)象進(jìn)行功能增強(qiáng)時(shí)，可以自定義類(lèi)，將原有對(duì)象傳入，基于已有的功能，并提供增前功能，那么自定義的該類(lèi)稱(chēng)為裝飾類(lèi)（裝飾器）。裝飾器會(huì)通過(guò)構(gòu)造方法接收被裝飾的類(lèi)，并基于被裝飾的類(lèi)提供更強(qiáng)的功能。

裝飾設(shè)計(jì)模式包括抽象構(gòu)件、具體構(gòu)件、抽象裝飾類(lèi)和具體裝飾類(lèi)。這里的裝飾類(lèi)就是對(duì)具體構(gòu)件的增強(qiáng)，因此和具體構(gòu)建一樣都是繼承與抽象裝飾器。

Java中使用的最廣泛的裝飾器模式就是JavaIO類(lèi)的設(shè)計(jì)。比如，OutPutStream是輸出流的基類(lèi)，其子類(lèi)有FileOutputStream 和FilterOutputStream,而FilterOutputStream的子類(lèi)有BufferedOutputStream和DataOutputStream兩個(gè)子類(lèi)。其中，F(xiàn)ileOutputStream為系統(tǒng)的核心類(lèi)，它實(shí)現(xiàn)了向文件寫(xiě)數(shù)據(jù)的功能，使用DataOutputStream可以在FileOutputStream的基礎(chǔ)上增加多種數(shù)據(jù)類(lèi)型的寫(xiě)操作支持（DataOutputStream類(lèi)中有writeUTF、writeInt等函數(shù)），而B(niǎo)ufferdOutputStream裝飾器可以對(duì)FileOutputStream增加緩沖功能，優(yōu)化I/O性能。

外觀(guān)模式：

一個(gè)公司的門(mén)戶(hù)網(wǎng)站就是一個(gè)外觀(guān)模式的應(yīng)用?？紤]網(wǎng)站導(dǎo)航，有公司新聞、留言系統(tǒng)、產(chǎn)品介紹、在線(xiàn)論壇等導(dǎo)航。這樣我們先通過(guò)導(dǎo)航定位到不同的頁(yè)面，這樣總比直接找到某一頁(yè)面方便。外觀(guān)模式定義為：外部與一個(gè)子系統(tǒng)的通信必須通過(guò)一個(gè)統(tǒng)一的外觀(guān)對(duì)象進(jìn)行，為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，外觀(guān)模式定義了一個(gè)高層接口，這個(gè)接口使得降低了用戶(hù)和這些子系統(tǒng)的耦合度。

外觀(guān)設(shè)計(jì)模式的的設(shè)計(jì)目標(biāo)是使系統(tǒng)間的通信和相互依賴(lài)關(guān)系達(dá)到最小，而達(dá)到這個(gè)目標(biāo)的途徑之一就是引入外觀(guān)對(duì)象，它為 子系統(tǒng)的訪(fǎng)問(wèn)提供了一個(gè)簡(jiǎn)單而單一的入口，同時(shí)降低了客戶(hù)類(lèi)與子系統(tǒng)類(lèi)的耦合度。

在java中的應(yīng)用：jdbc數(shù)據(jù)庫(kù)操作，提供一個(gè)統(tǒng)一的類(lèi)來(lái)管理對(duì)數(shù)據(jù)庫(kù)的打開(kāi)、查詢(xún)和關(guān)閉操作。

享元設(shè)計(jì)模式：

如果系統(tǒng)中對(duì)象數(shù)量太多時(shí)，由于創(chuàng)建和銷(xiāo)毀對(duì)象都是很消耗資源的操作，不斷的產(chǎn)生新對(duì)象將導(dǎo)致運(yùn)行代價(jià)過(guò)高，帶來(lái)性能下降等問(wèn)題。享元模式正是為解決這類(lèi)問(wèn)題而誕生的。享元模式通過(guò)共享技術(shù)實(shí)現(xiàn)對(duì)象的重用。在享元模式中通常創(chuàng)建一個(gè)享元工廠(chǎng)來(lái)維護(hù)一個(gè)享元池用于存儲(chǔ)具有相同內(nèi)部狀態(tài)的享元對(duì)象。比如說(shuō)片5000個(gè)字母組成的英文文章，我們只需要保存26個(gè)字母對(duì)象和一些標(biāo)點(diǎn)符號(hào)對(duì)象集合，而不是保存5000個(gè)對(duì)象。因?yàn)橄嗤淖帜钙鋬?nèi)部狀態(tài)（比如其ascii碼相同）相同，而外部狀態(tài)，比如這個(gè)字母相對(duì)文章開(kāi)始的偏移量不同，因此這些相同的字母是可以共享的，只是在排列的時(shí)候被放到了不同的位置。

享元模式包括四種角色，抽象享元類(lèi)、具體享元類(lèi)、非共享具體享元類(lèi)和享元工廠(chǎng)類(lèi)。其中享元工廠(chǎng)類(lèi)維護(hù)一個(gè)享元抽象類(lèi)的hashMap，當(dāng)用戶(hù)需要具體享元對(duì)象的時(shí)候，不是直接創(chuàng)建對(duì)象，而是從享元工廠(chǎng)的這個(gè)hashMap中尋找時(shí)候有相同內(nèi)部狀態(tài)的對(duì)象，如果有則直接返回；如果沒(méi)有則創(chuàng)建并加入到這個(gè)集合后才返回。

Java中應(yīng)用享元設(shè)計(jì)模式的場(chǎng)景：JDK中定義String類(lèi)采用了享元設(shè)計(jì)模式。Jdk5的并發(fā)框架的線(xiàn)程池、以及Integer自動(dòng)裝箱（-128~127的整數(shù)）用到了享元設(shè)計(jì)模式，

代理設(shè)計(jì)模式：

在某些情況下，一個(gè)客戶(hù)不想直接引用一個(gè)對(duì)象，此時(shí)可以通過(guò)一個(gè)代理的第三者來(lái)實(shí)現(xiàn)間接引用，可以在客戶(hù)端和目標(biāo)對(duì)象之間起到中介的作用，并且可以通過(guò)生成代理增加或者刪除某些功能。

代理模式包括抽象主題角色、代理主題角色、和真實(shí)主題角色。抽象主題是真實(shí)主題和代理主題的共同接口，使得在任何使用真實(shí)主題的地方都可以使用代理主題（根據(jù)里氏代換原則），客戶(hù)端通常需要針對(duì)抽象主題角色編程。

代理模式的應(yīng)用：

1、JavaRMI的使用。

2、Spring框架中AOP技術(shù)也是代理的應(yīng)用，在Spring AOP中使用動(dòng)態(tài)代理技術(shù)。

3、Hibernate根據(jù)id進(jìn)行l(wèi)oad查詢(xún)時(shí)，也使用到了代理，用于延遲加載。此時(shí)，HIbernate使用一個(gè)動(dòng)態(tài)代理子類(lèi)替代用戶(hù)定義的類(lèi)，這樣在載入對(duì)象時(shí)，就不必初始化對(duì)象的所有信息。通過(guò)代理，攔截原有的getter方法，可以在真正使用對(duì)象數(shù)據(jù)時(shí)，才能從數(shù)據(jù)庫(kù)加載實(shí)際的數(shù)據(jù)，從而提升。

職責(zé)鏈設(shè)計(jì)模式：

系統(tǒng)中有很多能處理請(qǐng)求的對(duì)象。指責(zé)連模式將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，知道有一個(gè)對(duì)象處理這個(gè)請(qǐng)求為止。這樣，客戶(hù)端無(wú)須關(guān)心請(qǐng)求的處理細(xì)節(jié)以及請(qǐng)求的傳遞，只需將請(qǐng)求發(fā)送到鏈上即可，將請(qǐng)求的發(fā)送者個(gè)處理者解耦。

設(shè)計(jì)職責(zé)鏈時(shí)，→每一個(gè)對(duì)象及對(duì)其上級(jí)領(lǐng)導(dǎo)的引用而連接起來(lái)形成一條鏈。請(qǐng)求在這條鏈上傳遞，直到鏈上的某一個(gè)對(duì)象處理此請(qǐng)求為止，發(fā)出這個(gè)請(qǐng)求的客戶(hù)端并不知道鏈上哪一個(gè)對(duì)象最終處理這個(gè)請(qǐng)求，這使得系統(tǒng)可以在不影響客戶(hù)端的情況下動(dòng)態(tài)的重新分配和組織責(zé)任。

職責(zé)鏈模式在Java中使用最多的就是Java的異常處理機(jī)制。

觀(guān)察者模式：

觀(guān)察者模式建立一種對(duì)象與對(duì)象之間的依賴(lài)關(guān)系，一個(gè)對(duì)象發(fā)生改變時(shí)將自動(dòng)通知其他對(duì)象，其他對(duì)象將相應(yīng)做出反應(yīng)。

觀(guān)察者模式包括四種角色：目標(biāo)、具體目標(biāo)、觀(guān)察者、抽象觀(guān)察者。

應(yīng)用：

1、MVC框架，觀(guān)察目標(biāo)為MVC中的model，而觀(guān)察者就是MVC的View，而Controller充當(dāng)兩者之間的中介者，當(dāng)模型層的數(shù)據(jù)發(fā)生改變時(shí)，試圖自動(dòng)改變其顯式內(nèi)容。

2、Java NIO中的非阻塞通道。SelectableChannel可以向Selector注冊(cè)讀就緒和寫(xiě)就緒等事件。Selector負(fù)責(zé)監(jiān)控這些事件，等到事件發(fā)生時(shí)，比如發(fā)生了讀就緒事件，SelectableChannel就可以執(zhí)行讀操作了。在這種通信模式中，Selector就充當(dāng)了觀(guān)察者。

3、Java語(yǔ)言提供了對(duì)觀(guān)察者模式的支持：在就JDK的java.util包中，提供了Observable目標(biāo)類(lèi)和Observer接口（抽象觀(guān)察者）。

模版設(shè)計(jì)模式：

需要定義一些頂級(jí)邏輯，或者是一個(gè)操作中算法的骨架，希望一些步驟的執(zhí)行推遲到子類(lèi)中。模版模式涉及到兩個(gè)角色，抽象模版和具體模版。抽象模版中定義了一個(gè)或多個(gè)操作，以便于讓子類(lèi)實(shí)現(xiàn)，這些操作是一個(gè)算法的邏輯和框架。以及一個(gè)模版方法，該模版方法是一個(gè)具體方法，它給出了抽象操作的實(shí)現(xiàn)邏輯。具體模版實(shí)現(xiàn)父類(lèi)所定義的一個(gè)或多個(gè)抽象方法，它們是一個(gè)頂級(jí)邏輯的組成步驟。

使用場(chǎng)景：

1、模版方法模式廣泛應(yīng)用于框架設(shè)計(jì)（如Spring，Struts等）中，以保證父類(lèi)控制處理路程的邏輯順序，比如Spring對(duì)于Hibernate使用的簡(jiǎn)單封裝：HibernateTemplate。

2、Java單元測(cè)試工具JUnit中的TestCase類(lèi)的設(shè)計(jì)。

命令設(shè)計(jì)模式：

在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，一個(gè)對(duì)象調(diào)用另一個(gè)對(duì)象，一般情況下的調(diào)用過(guò)程是：創(chuàng)建目標(biāo)對(duì)象實(shí)例、設(shè)置調(diào)用參數(shù)、調(diào)用目標(biāo)對(duì)象的方法。但是有些情況下有必要使用一個(gè)專(zhuān)門(mén)的類(lèi)對(duì)這種調(diào)用過(guò)程加以封裝，這種類(lèi)叫做command類(lèi)。

命令模式的本質(zhì)是對(duì)命令進(jìn)行封裝，將發(fā)出命令的責(zé)任個(gè)執(zhí)行命令的責(zé)任分隔開(kāi)。每一個(gè)命令都是一個(gè)操作，請(qǐng)求的一方發(fā)出請(qǐng)求，要求執(zhí)行一個(gè)動(dòng)作，接收的一方收到請(qǐng)求，并執(zhí)行操作。命令模式允許請(qǐng)求的一方和接收的一方獨(dú)立開(kāi)來(lái)，使得請(qǐng)求的一方不必知道接受請(qǐng)求的一方的接口，更不必知道請(qǐng)求是怎樣被接收，以及操作是否被執(zhí)行、何時(shí)被執(zhí)行以及怎樣被執(zhí)行的。命令模式的關(guān)鍵在于引入了抽象命令接口，且發(fā)送者針對(duì)命令接口編程，只有實(shí)現(xiàn)了抽象命令接口的具體命令才能被接受者相關(guān)聯(lián)。

命令模式包括5個(gè)角色：

命令角色，聲明執(zhí)行操作的接口，一般為接口或抽象類(lèi)。

具體命令角色：將一個(gè)接收者對(duì)象綁定于一個(gè)動(dòng)作，調(diào)用接收者相應(yīng)的操作，以實(shí)現(xiàn)命令角色生命的執(zhí)行操作的接口。

客戶(hù)角色：創(chuàng)建一個(gè)具體命令對(duì)象，并可以設(shè)定它的接收者。

調(diào)用者角色：調(diào)用命令對(duì)象執(zhí)行這個(gè)請(qǐng)求。

接收者角色：知道如何實(shí)施與執(zhí)行一個(gè)請(qǐng)求相關(guān)的操作。任何類(lèi)都可以作為一個(gè)接收者。

適用場(chǎng)景：現(xiàn)實(shí)中的遙控器。

中介者模式：

在面向?qū)ο蟮能浖O(shè)計(jì)與開(kāi)發(fā)過(guò)程中，根據(jù)單一職責(zé)原則，我們應(yīng)該將對(duì)象細(xì)化，使其只負(fù)責(zé)或呈現(xiàn)單一的職責(zé)。對(duì)于一個(gè)模塊，可能有很多對(duì)象構(gòu)成，而且這些對(duì)象之間可能存在相互的引用，為了減少對(duì)象之間復(fù)雜的引用關(guān)系，使之成為一個(gè)松耦合的系統(tǒng)，我們需要使用中介者模式。

中介者模式包括抽象中介者、具體中介者、抽象同事類(lèi)、具體同事類(lèi)。

這里餓中介者有兩方面的作用：中轉(zhuǎn)作用。通過(guò)中轉(zhuǎn)作用，各個(gè)同事對(duì)象不再需要顯示的引用其他同事。同事之間通信時(shí)候通過(guò)中介者即可。協(xié)調(diào)作用。中介者可以更進(jìn)一步的對(duì)同事之間的關(guān)系進(jìn)行封裝。

適用場(chǎng)景：

1、MVC 是Java EE 的一個(gè)基本模式，此時(shí)控制器Controller作為一種中介者，它負(fù)責(zé)控制視圖對(duì)象View和模型對(duì)象Model之間的交互。如在Struts中，Action就可以作為JSP頁(yè)面與業(yè)務(wù)對(duì)象之間的中介者。

2、QQ群原理。QQ群作為人與人之間的中介者，把人組織起來(lái)，負(fù)責(zé)人與人之間的交互。

狀態(tài)模式：

很多情況下，一個(gè)對(duì)象的行為取決于一個(gè)或多個(gè)動(dòng)態(tài)變化的屬性，這樣的屬性叫做狀態(tài)。當(dāng)一個(gè)這樣的對(duì)象與外部事件產(chǎn)生交互時(shí)，其內(nèi)部狀態(tài)就會(huì)改變，使得系統(tǒng)的行為也隨之發(fā)生變化。

比如，以論壇用戶(hù)等級(jí)為例。在這個(gè)論壇系統(tǒng)中，用戶(hù)發(fā)表留言、回復(fù)留言增加積分；用戶(hù)下載文件將扣除積分。假設(shè)將用戶(hù)等級(jí)分為初級(jí)用戶(hù)、中級(jí)用戶(hù)和高級(jí)用戶(hù)。如果用戶(hù)積分小于100分，將處于初級(jí)用戶(hù)狀態(tài)，此時(shí)不能下載文件。如果積分大于100分但小于1000分，則為中級(jí)狀態(tài)，用戶(hù)可以下載文件，而且發(fā)表留言的時(shí)候可以獲取雙倍積分。若積分大于1000，不但發(fā)表留言獲取雙倍積分，而且下載文件只扣除一半積分。這種情況下，用戶(hù)只需要進(jìn)行正常的論壇操作，回復(fù)帖子、發(fā)帖子、下載等操作，系統(tǒng)會(huì)根據(jù)積分狀態(tài)自動(dòng)轉(zhuǎn)換到相應(yīng)的狀態(tài)。

像這種，用戶(hù)的行為隨其等級(jí)不同而發(fā)生改變的場(chǎng)景可以使用狀態(tài)模式。

狀態(tài)模式包括環(huán)境類(lèi)、抽象狀態(tài)類(lèi)、具體狀態(tài)類(lèi)。一般環(huán)境類(lèi)中會(huì)關(guān)聯(lián)一個(gè)狀態(tài)類(lèi)。

使用場(chǎng)景：

在政府OA辦公系統(tǒng)中，一個(gè)批文的狀態(tài)有多種：尚未辦理；正在辦理；正在批示；正在審核；已經(jīng)完成等各種狀態(tài)，而且批文狀態(tài)不同時(shí)對(duì)批文的操作也有所差異。使用狀態(tài)模式可以描述工作流對(duì)象（如批文）的狀態(tài)轉(zhuǎn)換以及不同狀態(tài)下它所具有的行為。

策略模式：

完成一項(xiàng)任務(wù)，往往可以有多種不同的方式，每一種方式稱(chēng)為一個(gè)策略，我們可以根據(jù)環(huán)境或者條件的不同選擇不同的策略來(lái)完成該項(xiàng)任務(wù)。在軟件開(kāi)發(fā)中也常常遇到這種情況，實(shí)現(xiàn)某個(gè)功能有多個(gè)路徑，此時(shí)可以使用一種設(shè)計(jì)模式來(lái)使得系統(tǒng)可以靈活地選擇解決途徑，特能夠方便的增加新的解決途徑。

定義一系列算法，將每一個(gè)算法封裝起來(lái)，并讓它們可以相互替換。此模式讓算法的變化不會(huì)影響到使用算法的用戶(hù)。

策略模式包括環(huán)境類(lèi)、抽象策略類(lèi)、具體策略類(lèi)。

迭代器模式：

一個(gè)聚合對(duì)象，例如一個(gè)列表（List）或者一個(gè)集合（Set）應(yīng)該提供一種方法來(lái)讓別人可以訪(fǎng)問(wèn)它的元素，而又不需要它的內(nèi)部結(jié)構(gòu)。針對(duì)不同的需要，可能還要以不同的方式遍歷整個(gè)聚合對(duì)象，但是我們并不希望在聚合對(duì)象的抽象噌接口中充斥者各種不同遍歷的操作。怎樣一個(gè)聚合對(duì)象，又不需要了解聚合對(duì)象的內(nèi)部結(jié)構(gòu)，還能提供多種不同的遍歷方式，即是迭代器的動(dòng)機(jī)。

迭代器模式包括抽象聚合類(lèi)、具體聚合類(lèi)、抽象迭代器、具體迭代器。

想要了解更多設(shè)計(jì)模式詳解、架構(gòu)技術(shù)知識(shí)點(diǎn)的，可以關(guān)注我一下，我后續(xù)也會(huì)整理更多這一塊的知識(shí)點(diǎn)分享出來(lái)，另外順便給大家推薦一個(gè)交流學(xué)習(xí)群：650385180，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多，以下的課程體系圖也是在群里獲取。

總結(jié)：

以上就是我要說(shuō)的內(nèi)容，希望以上的內(nèi)容可以幫助到正在默默艱辛，遇到瓶疾且不知道怎么辦的Java程序員們，我能幫你的只有這么多了，希望大家在往后的工作與面試中，一切順利。