摘要：抽象工廠模式是為了處理對象具有等級結構以及對象族的問題。單例設計模式單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例，這個類成為單例類。

導語：設計模式是無數碼農前人在實際的生產項目中經過不斷的踩坑、爬坑、修坑的經歷總結出來的經驗教訓，經過抽象之后表達成的概念。能夠幫助后來的設計者避免重復同樣的錯誤或者彎路。我也抽空整理了一下設計模式，用自己的話總結了一下，自認為通俗易懂。覺得有用的朋友可以收藏一下。

簡單工廠模式：

包括三種角色，抽象產品、具體產品和工廠角色。其中在工廠直接完成對具體產品的創建。工廠模式的好處是需要創建對象的時候只需要輸入一個正確的參數就可以獲得所需要的對象，而無需知道其創建細節，這種模式將對象的創建和對象業務的處理分離，降低系統的耦合度，使得兩者修改起來都相對容易。

工廠方法模式：

該模式包括四種角色，抽象工廠、具體工廠、抽象產品和具體產品角色。與簡單工廠模式相比，抽象工廠負責定義創建產品對象的公共接口，而工廠子類則負責生產具體的產品對象。這樣可以將產品類的實例化操作延遲到工廠子類中完成。這樣，當需要生成一個具體產品對象時，首先要生成該對象的產品工廠。這樣的好處是可擴展性很好。

抽象工廠模式：

在工廠方法模式中，具體工廠負責生產具體的產品，每一個具體工廠對應一種具體產品，工廠方法也具有唯一性，一般情況下一個具體工廠中只有一工廠方法或者一組重載的工廠方法，但是有的時候我們需要一個工廠可以提供多個產品對象，而不是單一的產品對象。抽象工廠模式是為了處理對象具有等級結構以及對象族的問題。對象的等級結構即是對象的繼承結構，比如電視機是一個抽象父類，其子類有海爾電視機、海信電視機、TCL電視機等。對象族：是指同一個工廠生產的、位于不同對象等級結構中的一組對象。如海爾生產的海爾電視機、海爾電冰箱，這兩個都位于海爾電器的產品族中，其中海爾電視機位于電視機等級結構中，海爾電冰箱位于電冰箱等級結構中。

抽象工廠模式包括抽象工廠、具體工廠、抽象產品、具體產品4中角色。每一個具體工廠代表了一個對象族，都提供了多個工廠方法用于生產多種不同類型的產品，這些產品構成了一個對象族。

使用抽象工廠模式創建對象的時候，首先創建對應該對象族的工廠，然后調用該工廠中創建該對象的方法。

建造者模式：

建造者模式講一個復雜對象的構建與它的表示分離，使得童顏的構建過程可以創建不同的表示，它允許用戶只通過指定復雜對象的類型和內容就可以創建它們，而不需要參與內部的具體構建細節。建造者模式包括4種角色：指揮者角色、抽象構造者角色、具體構造者角色以及產品角色。具體構造者負責生成具體的對象、指揮者一方面隔離了客戶和生產過程，另一方面負責監控產品的生成過程，比如復雜對象的各個部分是以怎樣的順序生成等。指揮者針對抽象建造者編程，客戶端只需要知道具體構造者的類型，即可通過指揮者類調用構造者的相關方法，返回一個完整的產品對象。

距離說明，去KFC點餐的過程。一份套餐需要三個對象組成，即：可樂、漢堡和薯條。生產這些對象的師傅即為具體建造者，服務員為指揮者，套餐為產品角色。顯然，師傅在后臺如何生產這些產品我們并不知道，而是有服務員把這些對象構造成一份套餐。

原型模式：

原型設計模式：如果一些對象的創建構成比較復雜，而且有時候需要頻繁的創建，原型模式通過給出一個原型對象來指明索要創建的對象的類型，然后用復制這個原型的辦法創建出跟多同類型的對象。淺拷貝、深拷貝。

原型模式的適用場景：

Struts2中為了保證線程安全性，Action對象的創建使用了原型模式，訪問一個已經存在的Action時將通過克隆的方式創建出一個新的對象。從而保證其中定義的變量無須進行加鎖實現同步，每一個Action中都有自己的成員變量，避免Struts1因使用單例模式而導致的并發和同步問題。

Spring中，用戶也可以采用原型來創建新的bean實例，從而實現每次獲取的是通過克隆生成的新實例，對其進行修改時對原有實例對象不造成任何影響。

單例設計模式：

單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例，這個類成為單例類。單例模式的實現一般是構造函數私有化、自行實例化一個實例并提供靜態函數供整個系統訪問這個實例。其應用場景包括：java.lang.Runtimr類、線程池ThreadPool類中。

適配器設計模式：

適配器模式是將一個類的接口轉換成客戶希望的另一個接口，使得原本由于接口不兼容而不能一起工作的類可以一起工作。包括四個角色：客戶端、目標接口、適配器、適配者。

適用場景：已經存在的類的接口具有實用的功能但是不符合我們的要求。比如我們在程序中某個類C最終面對的是A接口或抽象類，因此類C只能使用A的子類或者實現類。假設我們有B類含有特殊的操作或功能，現在我們想在自己的系統中使用它，我們可以將其轉化成符合我們的標準的類。這樣，C類就可以在透明的情況下任意的選擇使用C類的子類或者具有特殊功能的B類。根據轉化的方式可以分為類適配器和對象適配器。

類適配器：自定義適配器，該適配器繼承自B，并且實現了A，這樣根據多態性，類C就可以很對該適配器編程。

對象適配器：適配器采用組合的形式，不再繼承B，而是關聯一個B對象。

適配器模式的應用場景：Hibernate自帶的日志系統是sel4j，自帶了一個jar包，slf4j-api-1.5.8.jar。打開這個jar包我們發現只是定義了一些接口，沒有具體實現。如果想用slf4j日志系統，需要引入slf4j-nop-1.5.8.jar實現jar包。但是這個日志系統沒有log4j使用的廣泛，因此Hibernate提供了一個jar包：slf4j-log4j12-1.5.8.jar，然后我們再引入log4j.jar，這樣通過slf4j-log4j12-1.5.8.jar的適配作用，我們就可以通過調用slf4j的接口使用log4j的日志功能。這是Hibernate中典型的適配器模式設計。

橋接模式：

橋接模式的設計思想是讓抽象部分與他的實現部分分離，使他們可以獨立的變化。它主要應對的是：由于實際的需要，某個類具有兩個或兩個以上的維度變化，如果只是用繼承將無法實現這種需要，或者使得設計變得相當臃腫。

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

我們可以把記錄記錄格式和日記記錄在不同平臺的實現分別當作兩個獨立的部分來對待，對于日志記錄方式，類結構仍是databaseLog類和FileLog兩個類繼承Log類。對于日志記錄平臺，引入另外一個抽象類，ImpLog，它是日志記錄在不同平臺上的實現的基類。這個時候，對于日志記錄方式和不同的運行平臺這兩個類可以獨立的變化了。我們要做的就是把這兩個部分連接起來。在這里使用對象組合的方式，即在Log類中關聯一個ImpLog對象。可以看到，通過對象組合的方式，Bridge模式把兩個角色之間的繼承關系改為了耦合的關系，從而使這兩者可以從容自若的各自獨立的變化，這也是Bridge模式的本意。

1、JDBC驅動程序也是橋接模式的應用之一。使用JDBC驅動程序的應用系統就是抽象角色，而所使用的數據庫是實現角色。一個JDBC驅動程序可以動態地將一個特定類型的數據庫與一個Java應用程序綁定在一起，從而實現抽象角色與實現角色的動態耦合。

組合模式：

組合模式描述了如何將容器對象和葉子對象進行遞歸組合，使得用戶在使用時無須對它們進行區分，可以一致的對待容器對象和葉子對象。組合多個對象形成鼠樹形結構以表示整體部分的層次結構。組合模式對但對象（即葉子對象）和組合對象（容器對象）的使用具有一致性。組合模式包括抽象組件、葉子組件和容器組件以及客戶類。

組合模式的關鍵是定義了一個抽象類，他既可以代表葉子，也可以代表容器，而客戶端針對該抽象組件進行編程，無須知道它到底表示的是葉子還是容器，可以對其進行統一的處理。同時容器對象與抽象構件之間還存在一個聚合關聯關系，在容器對象中既可以包含葉子也可以包含容器。比如文件系統的UML圖。

實現組合模式有兩種思路（1）在抽象組件中定義葉子節點和容器節點公共的方法，比如定義一個表示文件系統節點的抽象組件，可以只定義顯示名稱的方法，這樣在容器組件中擴展抽象組件的方法。（2）在抽象組件中明確定義容器節點所有的方法，這些方法有些肯定是葉子節點不能使用的，比如文件系統中葉子節點不會有remove刪除一個文件的方法。這時候抽象組件一般是一個抽象類，抽象類中對這些方法做了一般的處理，而在容器節點中根據功能進行相應的覆蓋。Java中XML文檔解析以及Java的AWT/SWing均用到了組合模式。

裝飾設計模式：

當想要對已有的對象進行功能增強時，可以自定義類，將原有對象傳入，基于已有的功能，并提供增前功能，那么自定義的該類稱為裝飾類（裝飾器）。裝飾器會通過構造方法接收被裝飾的類，并基于被裝飾的類提供更強的功能。

裝飾設計模式包括抽象構件、具體構件、抽象裝飾類和具體裝飾類。這里的裝飾類就是對具體構件的增強，因此和具體構建一樣都是繼承與抽象裝飾器。

Java中使用的最廣泛的裝飾器模式就是JavaIO類的設計。比如，OutPutStream是輸出流的基類，其子類有FileOutputStream 和FilterOutputStream,而FilterOutputStream的子類有BufferedOutputStream和DataOutputStream兩個子類。其中，FileOutputStream為系統的核心類，它實現了向文件寫數據的功能，使用DataOutputStream可以在FileOutputStream的基礎上增加多種數據類型的寫操作支持（DataOutputStream類中有writeUTF、writeInt等函數），而BufferdOutputStream裝飾器可以對FileOutputStream增加緩沖功能，優化I/O性能。

外觀模式：

一個公司的門戶網站就是一個外觀模式的應用。考慮網站導航，有公司新聞、留言系統、產品介紹、在線論壇等導航。這樣我們先通過導航定位到不同的頁面，這樣總比直接找到某一頁面方便。外觀模式定義為：外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得降低了用戶和這些子系統的耦合度。

外觀設計模式的的設計目標是使系統間的通信和相互依賴關系達到最小，而達到這個目標的途徑之一就是引入外觀對象，它為 子系統的訪問提供了一個簡單而單一的入口，同時降低了客戶類與子系統類的耦合度。

在java中的應用：jdbc數據庫操作，提供一個統一的類來管理對數據庫的打開、查詢和關閉操作。

享元設計模式：

如果系統中對象數量太多時，由于創建和銷毀對象都是很消耗資源的操作，不斷的產生新對象將導致運行代價過高，帶來性能下降等問題。享元模式正是為解決這類問題而誕生的。享元模式通過共享技術實現對象的重用。在享元模式中通常創建一個享元工廠來維護一個享元池用于存儲具有相同內部狀態的享元對象。比如說片5000個字母組成的英文文章，我們只需要保存26個字母對象和一些標點符號對象集合，而不是保存5000個對象。因為相同的字母其內部狀態（比如其ascii碼相同）相同，而外部狀態，比如這個字母相對文章開始的偏移量不同，因此這些相同的字母是可以共享的，只是在排列的時候被放到了不同的位置。

享元模式包括四種角色，抽象享元類、具體享元類、非共享具體享元類和享元工廠類。其中享元工廠類維護一個享元抽象類的hashMap，當用戶需要具體享元對象的時候，不是直接創建對象，而是從享元工廠的這個hashMap中尋找時候有相同內部狀態的對象，如果有則直接返回；如果沒有則創建并加入到這個集合后才返回。

Java中應用享元設計模式的場景：JDK中定義String類采用了享元設計模式。Jdk5的并發框架的線程池、以及Integer自動裝箱（-128~127的整數）用到了享元設計模式，

代理設計模式：

在某些情況下，一個客戶不想直接引用一個對象，此時可以通過一個代理的第三者來實現間接引用，可以在客戶端和目標對象之間起到中介的作用，并且可以通過生成代理增加或者刪除某些功能。

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

代理模式的應用：

1、JavaRMI的使用。

2、Spring框架中AOP技術也是代理的應用，在Spring AOP中使用動態代理技術。

3、Hibernate根據id進行load查詢時，也使用到了代理，用于延遲加載。此時，HIbernate使用一個動態代理子類替代用戶定義的類，這樣在載入對象時，就不必初始化對象的所有信息。通過代理，攔截原有的getter方法，可以在真正使用對象數據時，才能從數據庫加載實際的數據，從而提升。

職責鏈設計模式：

系統中有很多能處理請求的對象。指責連模式將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，知道有一個對象處理這個請求為止。這樣，客戶端無須關心請求的處理細節以及請求的傳遞，只需將請求發送到鏈上即可，將請求的發送者個處理者解耦。

設計職責鏈時，→每一個對象及對其上級領導的引用而連接起來形成一條鏈。請求在這條鏈上傳遞，直到鏈上的某一個對象處理此請求為止，發出這個請求的客戶端并不知道鏈上哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態的重新分配和組織責任。

職責鏈模式在Java中使用最多的就是Java的異常處理機制。

觀察者模式：

觀察者模式建立一種對象與對象之間的依賴關系，一個對象發生改變時將自動通知其他對象，其他對象將相應做出反應。

觀察者模式包括四種角色：目標、具體目標、觀察者、抽象觀察者。

應用：

1、MVC框架，觀察目標為MVC中的model，而觀察者就是MVC的View，而Controller充當兩者之間的中介者，當模型層的數據發生改變時，試圖自動改變其顯式內容。

2、Java NIO中的非阻塞通道。SelectableChannel可以向Selector注冊讀就緒和寫就緒等事件。Selector負責監控這些事件，等到事件發生時，比如發生了讀就緒事件，SelectableChannel就可以執行讀操作了。在這種通信模式中，Selector就充當了觀察者。

3、Java語言提供了對觀察者模式的支持：在就JDK的java.util包中，提供了Observable目標類和Observer接口（抽象觀察者）。

模版設計模式：

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

使用場景：

1、模版方法模式廣泛應用于框架設計（如Spring，Struts等）中，以保證父類控制處理路程的邏輯順序，比如Spring對于Hibernate使用的簡單封裝：HibernateTemplate。

2、Java單元測試工具JUnit中的TestCase類的設計。

命令設計模式：

在面向對象的程序設計中，一個對象調用另一個對象，一般情況下的調用過程是：創建目標對象實例、設置調用參數、調用目標對象的方法。但是有些情況下有必要使用一個專門的類對這種調用過程加以封裝，這種類叫做command類。

命令模式的本質是對命令進行封裝，將發出命令的責任個執行命令的責任分隔開。每一個命令都是一個操作，請求的一方發出請求，要求執行一個動作，接收的一方收到請求，并執行操作。命令模式允許請求的一方和接收的一方獨立開來，使得請求的一方不必知道接受請求的一方的接口，更不必知道請求是怎樣被接收，以及操作是否被執行、何時被執行以及怎樣被執行的。命令模式的關鍵在于引入了抽象命令接口，且發送者針對命令接口編程，只有實現了抽象命令接口的具體命令才能被接受者相關聯。

命令模式包括5個角色：

命令角色，聲明執行操作的接口，一般為接口或抽象類。

具體命令角色：將一個接收者對象綁定于一個動作，調用接收者相應的操作，以實現命令角色生命的執行操作的接口。

客戶角色：創建一個具體命令對象，并可以設定它的接收者。

調用者角色：調用命令對象執行這個請求。

接收者角色：知道如何實施與執行一個請求相關的操作。任何類都可以作為一個接收者。

適用場景：現實中的遙控器。

中介者模式：

在面向對象的軟件設計與開發過程中，根據單一職責原則，我們應該將對象細化，使其只負責或呈現單一的職責。對于一個模塊，可能有很多對象構成，而且這些對象之間可能存在相互的引用，為了減少對象之間復雜的引用關系，使之成為一個松耦合的系統，我們需要使用中介者模式。

中介者模式包括抽象中介者、具體中介者、抽象同事類、具體同事類。

這里餓中介者有兩方面的作用：中轉作用。通過中轉作用，各個同事對象不再需要顯示的引用其他同事。同事之間通信時候通過中介者即可。協調作用。中介者可以更進一步的對同事之間的關系進行封裝。

適用場景：

1、MVC 是Java EE 的一個基本模式，此時控制器Controller作為一種中介者，它負責控制視圖對象View和模型對象Model之間的交互。如在Struts中，Action就可以作為JSP頁面與業務對象之間的中介者。

2、QQ群原理。QQ群作為人與人之間的中介者，把人組織起來，負責人與人之間的交互。

狀態模式：

很多情況下，一個對象的行為取決于一個或多個動態變化的屬性，這樣的屬性叫做狀態。當一個這樣的對象與外部事件產生交互時，其內部狀態就會改變，使得系統的行為也隨之發生變化。

比如，以論壇用戶等級為例。在這個論壇系統中，用戶發表留言、回復留言增加積分；用戶下載文件將扣除積分。假設將用戶等級分為初級用戶、中級用戶和高級用戶。如果用戶積分小于100分，將處于初級用戶狀態，此時不能下載文件。如果積分大于100分但小于1000分，則為中級狀態，用戶可以下載文件，而且發表留言的時候可以獲取雙倍積分。若積分大于1000，不但發表留言獲取雙倍積分，而且下載文件只扣除一半積分。這種情況下，用戶只需要進行正常的論壇操作，回復帖子、發帖子、下載等操作，系統會根據積分狀態自動轉換到相應的狀態。

像這種，用戶的行為隨其等級不同而發生改變的場景可以使用狀態模式。

狀態模式包括環境類、抽象狀態類、具體狀態類。一般環境類中會關聯一個狀態類。

使用場景：

在政府OA辦公系統中，一個批文的狀態有多種：尚未辦理；正在辦理；正在批示；正在審核；已經完成等各種狀態，而且批文狀態不同時對批文的操作也有所差異。使用狀態模式可以描述工作流對象（如批文）的狀態轉換以及不同狀態下它所具有的行為。

策略模式：

完成一項任務，往往可以有多種不同的方式，每一種方式稱為一個策略，我們可以根據環境或者條件的不同選擇不同的策略來完成該項任務。在軟件開發中也常常遇到這種情況，實現某個功能有多個路徑，此時可以使用一種設計模式來使得系統可以靈活地選擇解決途徑，特能夠方便的增加新的解決途徑。

定義一系列算法，將每一個算法封裝起來，并讓它們可以相互替換。此模式讓算法的變化不會影響到使用算法的用戶。

策略模式包括環境類、抽象策略類、具體策略類。

迭代器模式：

一個聚合對象，例如一個列表（List）或者一個集合（Set）應該提供一種方法來讓別人可以訪問它的元素，而又不需要它的內部結構。針對不同的需要，可能還要以不同的方式遍歷整個聚合對象，但是我們并不希望在聚合對象的抽象噌接口中充斥者各種不同遍歷的操作。怎樣一個聚合對象，又不需要了解聚合對象的內部結構，還能提供多種不同的遍歷方式，即是迭代器的動機。

迭代器模式包括抽象聚合類、具體聚合類、抽象迭代器、具體迭代器。

想要了解更多設計模式詳解、架構技術知識點的，可以關注我一下，我后續也會整理更多這一塊的知識點分享出來，另外順便給大家推薦一個交流學習群：650385180，里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多，以下的課程體系圖也是在群里獲取。

總結：

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