建立型
1. Factory Method（工廠方法）
2. Abstract Factory（抽象工廠）
3. Builder（建造者）
4. Prototype（原型）

5. Singleton（單例）

結構型

6. Adapter Class/Object（介面卡）
7. Bridge（橋接）
8. Composite（組合）
9. Decorator（裝飾）
10. Facade（外觀）
11. Flyweight（享元）

12. Proxy（代理）

行為型

13. Interpreter（直譯器）
14. Template Method（模板方法）
15. Chain of Responsibility（責任鏈）
16. Command（命令）
17. Iterator（迭代器）
18. Mediator（中介者）
19. Memento（備忘錄）
20. Observer（觀察者）
21. State（狀態）
22. Strategy（策略）

23. Visitor（訪問者）

設計模式之間的關係圖：

二、設計模式的六大原則

1、開閉原則（Open Close Principle）

開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。

2、里氏代換原則（Liskov Substitution Principle）

里氏代換原則(Liskov Substitution Principle LSP)面向物件設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科

3、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：真對介面程式設計，依賴於抽象而不依賴於具體。

4、介面隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

5、迪米特法則（最少知道原則）（Demeter Principle）

為什麼叫最少知道原則，就是說：一個實體應當儘量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。

6、合成複用原則（Composite Reuse Principle）

原則是儘量使用合成/聚合的方式，而不是使用繼承。

三、Java的23中設計模式

從這一塊開始，我們詳細介紹Java中23種設計模式的概念，應用場景等情況，並結合他們的特點及設計模式的原則進行分析。

1、工廠方法模式（Factory Method）

工廠方法模式分為三種：

11、普通工廠模式，就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。首先看下關係圖：

舉例如下：（我們舉一個傳送郵件和簡訊的例子）

首先，建立二者的共同介面：

1. publicinterface Sender {  
2.     publicvoid Send();  
3. }  

其次，建立實現類：

1. publicclass MailSender implements Sender {  
2.     @Override
3.     publicvoid Send() {  
4.         System.out.println("this is mailsender!");  
5.     }  
6. }  

1. publicclass SmsSender implements Sender {  
2.     @Override
3.     publicvoid Send() {  
4.         System.out.println("this is sms sender!");  
5.     }  
6. }  

最後，建工廠類：

1. publicclass SendFactory {  
2.     public Sender produce(String type) {  
3.         if ("mail".equals(type)) {  
4.             returnnew MailSender();  
5.         } elseif ("sms".equals(type)) {  
6.             returnnew SmsSender();  
7.         } else {  
8.             System.out.println("請輸入正確的型別!");  
9.             returnnull;  
10.         }  
11.     }  
12. }  

我們來測試下：

1. publicclass FactoryTest {  
2.     publicstaticvoid main(String[] args) {  
3.         SendFactory factory = new SendFactory();  
4.         Sender sender = factory.produce("sms");  
5.         sender.Send();  
6.     }  
7. }  

輸出：this is sms sender!

22、多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字串出錯，則不能正確建立物件，而多個工廠方法模式是提供多個工廠方法，分別建立物件。關係圖：

將上面的程式碼做下修改，改動下SendFactory類就行，如下：

[java] view plaincopypublicclass SendFactory {   public Sender produceMail(){  

1.         returnnew MailSender();  
2.     }  
3.     public Sender produceSms(){  
4.         returnnew SmsSender();  
5.     }  
6. }  

測試類如下：

1. publicclass FactoryTest {  
2.     publicstaticvoid main(String[] args) {  
3.         SendFactory factory = new SendFactory();  
4.         Sender sender = factory.produceMail();  
5.         sender.Send();  
6.     }  
7. }  

輸出：this is mailsender!

33、靜態工廠方法模式，將上面的多個工廠方法模式裡的方法置為靜態的，不需要建立例項，直接呼叫即可。

1. publicclass SendFactory {  
2.     publicstatic Sender produceMail(){  
3.         returnnew MailSender();  
4.     }  
5.     publicstatic Sender produceSms(){  
6.         returnnew SmsSender();  
7.     }  
8. }  

1. publicclass FactoryTest {  
2.     publicstaticvoid main(String[] args) {      
3.         Sender sender = SendFactory.produceMail();  
4.         sender.Send();  
5.     }  
6. }  

輸出：this is mailsender!

總體來說，工廠模式適合：凡是出現了大量的產品需要建立，並且具有共同的介面時，可以通過工廠方法模式進行建立。在以上的三種模式中，第一種如果傳入的字串有誤，不能正確建立物件，第三種相對於第二種，不需要例項化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。

2、抽象工廠模式（Abstract Factory）

工廠方法模式有一個問題就是，類的建立依賴工廠類，也就是說，如果想要拓展程式，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，建立多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的程式碼。因為抽象工廠不太好理解，我們先看看圖，然後就和程式碼，就比較容易理解。

請看例子：

1. publicinterface Sender {  
2.     publicvoid Send();  
3. }  

兩個實現類：

1. publicclass MailSender implements Sender {  
2.     @Override
3.     publicvoid Send() {  
4.         System.out.println("this is mailsender!");  
5.     }  
6. }  

1. publicclass SmsSender implements Sender {  
2.     @Override
3.     publicvoid Send() {  
4.         System.out.println("this is sms sender!");  
5.     }  
6. }  

兩個工廠類：

1. publicclass SendMailFactory implements Provider {  
2.     @Override
3.     public Sender produce(){  
4.         returnnew MailSender();  
5.     }  
6. }  

1. publicclass SendSmsFactory implements Provider{  
2.     @Override
3.     public Sender produce() {  
4.         returnnew SmsSender();  
5.     }  
6. }  

在提供一個介面：

1. publicinterface Provider {  
2.     public Sender produce();  
3. }  

測試類：

1. publicclass Test {  
2.     publicstaticvoid main(String[] args) {  
3.         Provider provider = new SendMailFactory();  
4.         Sender sender = provider.produce();  
5.         sender.Send();  
6.     }  
7. }  

其實這個模式的好處就是，如果你現在想增加一個功能：發及時資訊，則只需做一個實現類，實現Sender介面，同時做一個工廠類，實現Provider介面，就OK了，無需去改動現成的程式碼。這樣做，拓展性較好！

3、單例模式（Singleton）

單例物件（Singleton）是一種常用的設計模式。在Java應用中，單例物件能保證在一個JVM中，該物件只有一個例項存在。這樣的模式有幾個好處：

1、某些類建立比較頻繁，對於一些大型的物件，這是一筆很大的系統開銷。

2、省去了new操作符，降低了系統記憶體的使用頻率，減輕GC壓力。

3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以建立多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

首先我們寫一個簡單的單例類：

1. publicclass Singleton {  
2.     /* 持有私有靜態例項，防止被引用，此處賦值為null，目的是實現延遲載入 */
3.     privatestatic Singleton instance = null;  
4.     /* 私有構造方法，防止被例項化 */
5.     private Singleton() {  
6.     }  
7.     /* 靜態工程方法，建立例項 */
8.     publicstatic Singleton getInstance() {  
9.         if (instance == null) {  
10.             instance = new Singleton();  
11.         }  
12.         return instance;  
13.     }  
14.     /* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
15.     public Object readResolve() {  
16.         return instance;  
17.     }  
18. }  

這個類可以滿足基本要求，但是，像這樣毫無執行緒安全保護的類，如果我們把它放入多執行緒的環境下，肯定就會出現問題了，如何解決？我們首先會想到對getInstance方法加synchronized關鍵字，如下：

1. publicstaticsynchronized Singleton getInstance() {  
2.         if (instance == null) {  
3.             instance = new Singleton();  
4.         }  
5.         return instance;  
6.     }  

但是，synchronized關鍵字鎖住的是這個物件，這樣的用法，在效能上會有所下降，因為每次呼叫getInstance()，都要對物件上鎖，事實上，只有在第一次建立物件的時候需要加鎖，之後就不需要了，所以，這個地方需要改進。我們改成下面這個：

1. publicstatic Singleton getInstance() {  
2.         if (instance == null) {  
3.             synchronized (instance) {  
4.                 if (instance == null) {  
5.                     instance = new Singleton();  
6.                 }  
7.             }  
8.         }  
9.         return instance;  
10.     }  

似乎解決了之前提到的問題，將synchronized關鍵字加在了內部，也就是說當呼叫的時候是不需要加鎖的，只有在instance為null，並建立物件的時候才需要加鎖，效能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中建立物件和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序，也就是說有可能JVM會為新的Singleton例項分配空間，然後直接賦值給instance成員，然後再去初始化這個Singleton例項。這樣就可能出錯了，我們以A、B兩個執行緒為例：

a>A、B執行緒同時進入了第一個if判斷

b>A首先進入synchronized塊，由於instance為null，所以它執行instance = new Singleton();

c>由於JVM內部的優化機制，JVM先畫出了一些分配給Singleton例項的空白記憶體，並賦值給instance成員（注意此時JVM沒有開始初始化這個例項），然後A離開了synchronized塊。

d>B進入synchronized塊，由於instance此時不是null，因此它馬上離開了synchronized塊並將結果返回給呼叫該方法的程式。

e>此時B執行緒打算使用Singleton例項，卻發現它沒有被初始化，於是錯誤發生了。

所以程式還是有可能發生錯誤，其實程式在執行過程是很複雜的，從這點我們就可以看出，尤其是在寫多執行緒環境下的程式更有難度，有挑戰性。我們對該程式做進一步優化：

1. privatestaticclass SingletonFactory{           
2.         privatestatic Singleton instance = new Singleton();           
3.     }           
4.     publicstatic Singleton getInstance(){           
5.         return SingletonFactory.instance;           
6.     }   

實際情況是，單例模式使用內部類來維護單例的實現，JVM內部的機制能夠保證當一個類被載入的時候，這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫getInstance的時候，JVM能夠幫我們保證instance只被建立一次，並且會保證把賦值給instance的記憶體初始化完畢，這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制，這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式：

1. publicclass Singleton {  
2.     /* 私有構造方法，防止被例項化 */
3.     private Singleton() {  
4.     }  
5.     /* 此處使用一個內部類來維護單例 */
6.     privatestaticclass SingletonFactory {  
7.         privatestatic Singleton instance = new Singleton();  
8.     }  
9.     /* 獲取例項 */
10.     publicstatic Singleton getInstance() {  
11.         return SingletonFactory.instance;  
12.     }  
13.     /* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
14.     public Object readResolve() {  
15.         return getInstance();  
16.     }  
17. }  

其實說它完美，也不一定，如果在建構函式中丟擲異常，例項將永遠得不到建立，也會出錯。所以說，十分完美的東西是沒有的，我們只能根據實際情況，選擇最適合自己應用場景的實現方法。也有人這樣實現：因為我們只需要在建立類的時候進行同步，所以只要將建立和getInstance()分開，單獨為建立加synchronized關鍵字，也是可以的：

1. 相關推薦

   GOF23種設計模式精解

   建立型 1. Factory Method（工廠方法） 2. Abstract Factory（抽象工廠） 3. Builder（建造者） 4. Prototype（原型） 5. Singleton（單例） 結構型 6. Adapter Class/Obje

   GoF23種設計模式之行為型模式之訪問者模式

   部分 strong 操作 定義 狀態 arraylist his tro 不同的 概述 表示一個作用於某對象結構中的各元素的操作。 它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。 適用性 1.一個對象結構包含很多

   GoF23種設計模式之行為型模式之模板方法

   title 開始 gof prim void strong 結構 currency 類圖 概述 定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。 TemplateMethod使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

   GOF23種設計模式

   代理模式（Proxy pattern） 核心作用： 通過代理，控制對物件的訪問,可以詳細控制訪問某個（某類）物件的方法，在呼叫這個方法前做前置處理，呼叫這個方法後做後置處理。 AOP(Aspect Oriented Programming面向切面程式設計）的核心實現機制。

   23種設計模式詳解

   設計模式關係圖 UML與設計原則 UML類圖快速入門 : https://blog.csdn.net/love905661433/article/details/84334960 設計原則簡介 : https://blog.csdn.net/love90566

   Java開發中的23種設計模式詳解(轉)

   資源：http://download.csdn.net/detail/zhangerqing/4835830 原文連結：http://blog.csdn.net/zhangerqing 設計模式（Design Patterns）                   

   Java開發中的23種設計模式詳解

   一、設計模式的分類 總體來說設計模式分為三大類： 建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。 結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。 行為型模式，共十一種：策

   Java中常用的10種設計模式詳解

   1. 觀察者模式 定義了物件之間的一對多的依賴，這樣一來，當一個物件改變時，它的所有的依賴者都會收到通知並自動更新。 對於JDK或者Andorid中都有很多地方實現了觀察者模式，比如XXXVi

   GOF23種設計模式概括

   GOF23種設計模式分為三種: 建立型模式[工廠方法模式] 結構型模式[（類）介面卡模式] 行為型模式[ 直譯器模式,模板方法模式]   建立型模式Creational Patterns 抽象工廠模式abstract factory：提供了一個建立一系列相關

   java 23種設計模式詳解

   設計模式的分類 總體來說設計模式分為三大類： 建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。 結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。 行為型模式，共十一種：策略模式

   Gof23種設計模式+簡單工廠設計模式總結（一）

   一、軟體設計模式的種類 1.建立型模式 如何建立物件 2.結構型模式 如何實現類和物件的組合 3.行為型模式 類和物件怎麼樣互動以及怎麼樣分配職責 二、設計模式的原則 高內聚、低耦合 1.單一職責原則 類的職責比較

   Java開發中的23種設計模式詳解(三)

    本章是關於設計模式的最後一講，會講到第三種設計模式——行為型模式，共11種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。 先來張圖，看看這11中模式的關係： 第一類：通過父類與子類的關

   面向物件GOF23種設計模式綜述

   一、什麼是設計模式        設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性、程式的重用性。        設計模式其

   設計模式（建立型）：Java常用23種設計模式之單例模式詳解以及Java程式碼實現

   可以說單例模式是所有設計模式中最簡單的一種。 單例模式就是說系統中對於某類的只能有一個物件，不可能出來第二個。 單例模式也是23中設計模式中在面試時少數幾個會要求寫程式碼的模式之一。主要考察的是多執行緒下面單例模式的執行緒安全性問題。 1.多執行緒安全單例模式例項一(不使用同步鎖)

   Redis 設計與實現之RDB 和 AOF 兩種持久化模式詳解

   在執行情況下， Redis 以資料結構的形式將資料維持在記憶體中， 為了讓這些資料在 Redis 重啟之後仍然可用， Redis 分別提供了 RDB 和 AOF 兩種持久化模式。 在 Redis 執行時， RDB 程式將當前記憶體中的資料庫快照儲存到磁碟檔案中， 在 Red

   24種設計模式大全-牛人詳解

   Adapter模式和Bridge模式具有一些共同的特徵。它們都給另一物件提供了一定程度上的間接性，因而有利於系統的靈活性。它們都涉及到從自身以外的一個介面向這個物件轉發請求。這些模式的不同之處主要在於它們各自的用途。Bridge模式主要是為了解決兩個已有介面之間不匹配的問題。它不考慮這些介面是怎樣實現的，也不

   Java IO詳解（兩種設計模式的分析）

   一。引子（概括地介紹Java的ＩＯ） 　　無論是哪種程式語言，輸入跟輸出都是重要的一部分，Java也不例外，而且Java將輸入／輸出的功能和使用範疇做了很大的擴充。它採用了流的 機制來實現輸入／輸出，所謂流，就是資料的有序排列，而流可以是從某個源（稱為流源或Source

   java23種設計模式-前五種型模式詳解

   走穿23種設計模式-前五種，建立型模式詳解總體來說設計模式分為三大類（23種）：建立型模式，共五種：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式。結構型模式，共七種。介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種。

   javascript設計模式詳解之命令模式

   這一 clas 例子 別了 logs 操作 book 技術 概念 　　每種設計模式的出現都是為了彌補語言在某方面的不足，解決特定環境下的問題。思想是相通的。只不過不同的設計語言有其特定的實現。對javascript這種動態語言來說，弱類型的特性，與生俱來的多態性，導致某些設

   Java中的24種設計模式與7大原則

   工廠模式 職責 需要 占位符 ati gre template 層次 cto 一、創建型模式 1、抽象工廠模式(Abstract factory pattern): 提供一個接口, 用於創建相關或依賴對象的家族, 而不需要指定具體類.2、生成器模式(Builder pat