感覺設計模式是看著簡單 ，但是一用就不會，23種設計模式，學的人頭大，相信大家都是這樣的

設計模式在程式設計師的面試中會被考到，通常是介紹其原理並說出優缺點。或者對比幾個比較相似的模式的異同點。在筆試中可能會出現畫出某個設計模式的UML圖這樣的題。雖說面試中佔的比重不大，但並不代表它不重要。恰恰相反，設計模式於程式設計師而言相當重要，它是我們寫出優秀程式的保障。設計模式與程式設計師的架構能力與閱讀原始碼的能力息息相關，非常值得我們深入學習。

面向物件的威力從這個小例子中只能看到冰山一角，好比一段兩公里的路程，坐飛機和走路花費的時間差不了多少。但當我們需要翻山越嶺、漂洋過海時，坐飛機的人就會將走路的人遠遠拋在後面。

面向物件的特點是可維護、可複用、可擴充套件、靈活性好，它真正強大的地方在於：隨著業務變得越來越複雜，面向物件依然能夠使得程式結構良好，而面向過程卻會導致程式越來越臃腫。

讓面向物件保持結構良好的祕訣就是設計模式。

熟練掌握各種設計模式，並能在實際程式設計開發中靈活運用它們，不僅能使程式碼更規範，重用性更高，同時也能保證程式碼的可靠性，提高開發效率。這段時間又系統看了設計模式的相關內容，
整理學習總結如下:

• 七個設計原則
• 建立型模式(5種)
• 結構型模式(7種)
• 行為型模式(11種)

總體來說設計模式分為三大類：(本文著重講解標紅)
建立型模式，共五種：工廠方法模式、 抽象工廠模式、 單例模式、 建造者模式、原型模式。
結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、 享元模式。
行為型模式，共十一種： 策略模式、模板方法模式、 觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

二.七個設計原則

面向物件程式設計有七大原則，即經常提到的Design Pattern，提倡它的根本原因是為了程式碼複用，增加可維護性。設計模式就是實現了這些原則，從而達到了程式碼複用、增加可維護性的目的。

因為設計模式就是基於這些原則的實現，所以很有必要了解這些原則，下面主要對面向物件程式設計的幾個原則進行簡單介紹。

1、單一職責原則 ( SRP )

英文全稱是Single Responsibility Principle，定義是一個類，應該只有一個引起它變化的原因。類變化的原因就是職責，如果一個類承擔的職責過多，就等於把這些職責耦合在一起了。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。而如果想要避免這種現象的發生，就要儘可能的遵守單一職責原則。此原則的核心就是解耦和增強內聚性。

2、開閉原則 ( OCP )
英文全稱是Open Close Principle，定義是軟體實體（包括類、模組、函式等）應該對於擴充套件時開放的，對於修改是封閉的。開閉原則是是面向物件設計中最重要的原則之一，其它很多的設計原則都是實現開閉原則的一種手段。

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

4、依賴倒置原則 ( DIP )
英文全稱是Dependence Inversion Principle，這個原則是開閉原則的基礎，依賴倒置原則就是要求呼叫者和被呼叫者都依賴抽象，這樣兩者沒有直接的關聯和接觸，在變動的時候，一方的變動不會影響另一方的變動。依賴倒置強調了抽象的重要性，針對介面程式設計，依賴於抽象而不依賴於具體。

5、介面隔離原則 ( ISP )
英文全稱是Interface Segregation Principle，這個原則的意思是使用多個隔離的介面，比使用單個介面要好。目的就是降低類之間的耦合度，便於軟體升級和維護。

6、最少知道原則(迪米特原則)
一個實體應當儘量少地與其他實體之間發生相互作用，使得系統功能模組相對獨立。通俗地說就是不要和陌生人說話，即一個物件應對其他物件有儘可能少的瞭解。迪米特法則的初衷在於降低類之間的耦合。由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係。

7、合成/聚合複用（CARP）
英文全稱是Composite Reuse Principle，合成/聚合複用原則經常又叫做合成複用原則。合成/聚合複用原則的潛臺詞是：我只是用你的方法，我們不一定是同類。繼承的耦合性更大，比如一個父類後來新增實現一個介面或者去掉一個介面，那子類可能會遭到毀滅性的編譯錯誤，但如果只是組合聚合，只是引用類的方法，就不會有這種巨大的風險，同時也實現了複用。

三.建立者模式(5種)

建立型模式是指這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用新的運算子直接例項化物件。這使得程式在判斷針對某個給定例項需要建立哪些物件時更加靈活

1.單例模式

• 定義

確保某一個類只有一個例項，並自行例項化向整個系統提供這個例項。

• 簡介

單例模式理解起來不難，典型例子有一個公司只能有一個CEO。它主要是為了保證一個類僅有一個例項，這個類中自己提供一個返回例項的方法，方法中先判斷系統是否已經有這個單例，如果有則返回，如果沒有則建立。如果建立多個例項會消耗過多的資源或者某種型別的物件只應該有且只有一個時，應該考慮使用單例模式。

• 實現

單例模式理解起來不難，重要的是需要掌握它的幾種常見寫法。
餓漢式:

public class Singleton {
// 直接建立物件
public static Singleton instance = new Singleton();
// 私有化建構函式
private Singleton() {
}
// 返回物件例項
public static Singleton getInstance() {
return instance;
}
}

懶漢式:

//寫法一、懶漢式寫法

public class Singleton {
 
    private static Singleton instance; 

    //建構函式私有
    private Singleton (){
    }  

    public static synchronized Singleton getInstance() { 
         if (instance == null) {  
             instance = new Singleton();  
         }  
         return instance;  
    }  
}  
 

//寫法二、DCL（Double Check Lock） 雙重校驗鎖

public class Singleton {  

    private volatile static Singleton singleton;  

    private Singleton (){
    }  

    public static Singleton getSingleton() {  

        if (singleton == null) {  
            synchronized (Singleton.class) {  
            if (singleton == null) {  
                singleton = new Singleton();  
            }  
          }  
        }  
        return singleton;  
    }  
} 
 

//寫法三、靜態內部類單例模式

public class Singleton {  

    private Singleton (){
    }  

    public static final Singleton getInstance() {  
          return SingletonHolder.INSTANCE;  
    }  

    private static class SingletonHolder {  
         private static final Singleton INSTANCE = new Singleton();  
    }
}   

上面的第一種懶漢式寫法做到了延遲建立和執行緒安全，缺點是每次呼叫getInstance()時都必須進行同步，效率不佳。第二種DCL方式比較常見，兩次判空，第一次判空避免了不必要的同步，第二次保證了單例建立，這種方式比較不錯，但是在高併發環境下有時會出現問題。第三種方法最被推薦，執行緒安全也保證了例項唯一。

2.工廠方法模式

• 定義

定義一個用於建立物件的介面，讓子類決定例項化哪一個類。

工廠方法模式分為三種：普通工廠模式，就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字串出錯，則不能正確建立物件，而多個工廠方法模式是提供多個工廠方法，分別建立物件。靜態工廠方法模式，將上面的多個工廠方法模式裡的方法置為靜態的，不需要建立例項，直接呼叫即可 .

(1)普通工廠模式

public interface Sender {
public void Send();
}
public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mail sender!");
}
}
public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}
public class SendFactory {
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
} else if ("sms".equals(type)) {
return new SmsSender();
} else {
System.out.println("請輸入正確的型別!");
return null;
}
}
}

(2)多個工廠模式

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

public class SendFactory {
public Sender produceMail(){
return new MailSender();
}
public Sender produceSms(){
return new SmsSender();
}
}
public class FactoryTest {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produceMail();
sender.send();
}
}

(3)靜態工廠模式

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

public class SendFactory {
 public static Sender produceMail(){
return new MailSender();
}
public static Sender produceSms(){
return new SmsSender();
}
}
public class FactoryTest {
public static void main(String[] args) {
Sender sender = SendFactory.produceMail();
sender.send();
}
}

3.抽象工廠模式

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

程式碼還是在工廠方法模式的基礎上改進

public interface Provider {
public Sender produce();
}
----------------------------------------------------------------------------
public interface Sender {
public void send();
}
----------------------------------------------------------------------------
public class MailSender implements Sender {
@Override
public void send() {
System.out.println("this is mail sender!");
}
}
---------------------------------------------------------------------------
public class SmsSender implements Sender {
@Override
public void send() {
System.out.println("this is sms sender!");
}
}
---------------------------------------------------------
public class SendSmsFactory implements Provider {
@Override
public Sender produce() {
return new SmsSender();
}
}
public class SendMailFactory implements Provider {
@Override
public Sender produce() {
return new MailSender();
}
}
-------------------------------------------------------------
public class Test {
public static void main(String[] args) {
Provider provider = new SendMailFactory();
Sender sender = provider.produce();
sender.send();
}
}

4.建造者模式(Builder)

工廠類模式提供的是建立單個類的模式，而建造者模式則是將各種產品集中起來進行管理，用來建立複合物件，所謂複合物件就是指某個類具有不同的屬性，其實建造者模式就是前面抽象工廠模式和最後的 Test 結合起來得到的

public class Builder {
private List<Sender> list = new ArrayList<Sender>();
public void produceMailSender(int count) {
for (int i = 0; i < count; i++) {
list.add(new MailSender());
}
}
public void produceSmsSender(int count) {
for (int i = 0; i < count; i++) {
list.add(new SmsSender());
}
}
}
 

public class TestBuilder {
public static void main(String[] args) {
Builder builder = new Builder();
builder.produceMailSender(10);
}
}

5.原型模式

• 定義

用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。

• 簡介

原型模式不難理解，它主要是用在例項建立的時候，因為有的時候我們通過new建立一個物件時可能成本過高，這時我們可以考慮直接通過直接克隆例項快速建立物件。克隆後的例項與原例項內部屬性一致。原型模式需要注意一個深拷貝和淺拷貝的問題。
四.結構型模式(7種)
結構型模式關注類和物件的組合。繼承的概念被用來組合介面和定義組合物件獲得新功能的方式。

1.介面卡設計模式

介面卡模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的相容性問題。主要分為三類：類的介面卡模式、物件的介面卡模式、介面的介面卡模式

• 類的介面卡模式

public class Source {
public void method1() {
System.out.println("this is original method!");
}
}
-------------------------------------------------------------
public interface Targetable {
/* 與原類中的方法相同 */
public void method1();
 /* 新類的方法 */
 public void method2();
 }
 public class Adapter extends Source implements Targetable {
 @Override
 public void method2() {
 System.out.println("this is the targetable method!");
 }
 }
 public class AdapterTest {
 public static void main(String[] args) {
 Targetable target = new Adapter();
 target.method1();
 target.method2();
 }
}

• 物件的介面卡模式

基本思路和類的介面卡模式相同，只是將 Adapter 類作修改，這次不繼承 Source 類，而是持有 Source 類的例項，以達到解決相容性的問題

public class Wrapper implements Targetable {
private Source source;
public Wrapper(Source source) {
super();
this.source = source;
}
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
@Override
public void method1() {
source.method1();
}
}
--------------------------------------------------------------
public class AdapterTest {
public static void main(String[] args) {
Source source = new Source();
Targetable target = new Wrapper(source);
target.method1();
target.method2();
}
}

• 介面的介面卡模式

介面的介面卡是這樣的：有時我們寫的一個介面中有多個抽象方法，當我們寫該介面的實現類時，必須實現該介面的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了介面的介面卡模式，藉助於一個抽象類，該抽象類實現了該介面，實現了所有的方法，而我們不和原始的介面打交道，只和該抽象類取得聯絡，所以我們寫一個類，繼承該抽象類，重寫我們需要的方法就行。

2.橋接模式

• 定義

將抽象部分與實現部分分離，使它們都可以獨立的變化。

• 簡介

在軟體系統中，某些型別由於自身的邏輯，它具有兩個或多個維度的變化，那麼如何應對這種“多維度的變化”？這就要使用橋接模式。橋接模式需要重點理解的抽象部分，實現部分，脫耦。一個典型的例子是咖啡加糖問題，抽象部分有Coffee，其下有LargeCoffee，SmallCoffee，實現部分是CoffeeAdd，其下有Sugar，Normal，抽象類Coffee中引用CoffeeAdd，這樣CoffeeAdd其實就是一個橋接。

3.裝飾模式
顧名思義，裝飾模式就是給一個物件增加一些新的功能，而且是動態的，要求裝飾物件和被裝飾物件實現同一個 介面，裝飾物件持有被裝飾物件的例項。

4.組合模式

• 定義

將物件組合成樹形結構以表示“部分-整體”的層次結構，使得使用者對單個物件和組合物件的使用具有一致性。

• 簡介

組合模式理解起來相對簡單，典型的例子就是假設公司A，裡面有不同的部門，不同的部分下有不同的員工，這樣一個部門下的所有員工組合成了一個部門，所有部門組合成了整個公司。

5.外觀模式

• 定義

為子系統中的一組介面提供一個一致的介面，外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

• 簡介

外觀模式的一個典型例子是去醫院看病，掛號、門診、劃價、取藥，讓患者或患者家屬覺得很複雜，如果有提供接待人員，只讓接待人員來處理，就很方便。

6.享元模式

• 定義

運用共享技術有效地支援大量細粒度的物件。

• 簡介

在有大量物件時，有可能會造成記憶體溢位，我們把其中共同的部分抽象出來，如果有相同的業務請求，直接返回在記憶體中已有的物件，避免重新建立。

7.代理模式

• 定義

為其他物件提供一種代理以控制對這個物件的訪問。

• 簡介

代理模式主要解決在直接訪問物件時帶來的問題。舉個例子，豬八戒去找高翠蘭結果是孫悟空變的，可以這樣理解：把高翠蘭的外貌抽象出來，高翠蘭本人和孫悟空都實現了這個介面，豬八戒訪問高翠蘭的時候看不出來這個是孫悟空，所以說孫悟空是高翠蘭代理類。

五、行為型模式 ( 11種 )

這些設計模式特別關注物件之間的通訊。

1.模板方法模式

• 定義

一個操作中的演算法的框架，而將一些步驟延遲到子類中，使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

• 例子

模板方法模式一個典型例子就是Android中的非同步任務類AsyncTask，它對非同步任務的執行進行了流程封裝，子類繼承它時，只需在指定的流程中實現具體的操作即可。

2.命令模式

• 定義

將一個請求封裝為一個物件，從而可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可取消的操作

• 簡介

命令模式主要是通過呼叫者呼叫接受者執行命令，這個模式中需要理解的是三個角色：(1) Receiver 真正的命令執行物件 (2) Command 持有一個對Receiver的引用，呼叫Receiver的相關方法。(3) Invoker 請求者，持有一個對Command的引用，呼叫Command的方法執行具體命令。

3.迭代器模式

• 定義

提供一種方法順序訪問一個聚合物件中各個元素, 而又不需暴露該物件的內部表示。

• 簡介

在Java集合框架中我們知道對於一個指定的集合類，我們可以使用一個特定的Iterator迭代器來對集合中的所有元素進行遍歷。這樣結合來看，迭代器模式很好理解了。

4.觀察者模式

• 定義

定義物件間的一種一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被自動更新。

• 簡介

觀察者模式可以結合Android中的ListView來理解，ListView關聯的介面卡Adapter在資料發生變化時會通過notifyDataSetChanged()方法來通知介面重新整理。

5.中介者模式

• 定義

用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。

• 簡介

中介者模式的典型例子就是未加入 WTO 之前各個國家相互貿易，結構複雜，大家都加入WTO後是各個國家通過 WTO 來互相貿易，變得規範。

6.備忘錄模式

• 定義

在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。

• 簡介

備忘錄模式的典型例子就是git版本管理工具，它幫我們儲存了每次提交後的專案狀態，在必要的時候我們可以回退到指定的版本中。

7.直譯器模式

• 定義

給定一個語言，定義它的文法的一種表示，並定義一個直譯器，這個直譯器使用該表示來解釋語言中的句子。

• 簡介

直譯器的典型例子是在編譯原理中的應用，如果一種特定型別的問題發生的頻率足夠高，那麼可能就值得將該問題的各個例項表述為一個簡單語言中的句子。這樣就可以構建一個直譯器，該直譯器通過解釋這些句子來解決該問題。

8.狀態模式

• 定義

允許一個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了它的類。

• 簡介

狀態模式主要解決物件的行為依賴於它的狀態（屬性），並且可以根據它的狀態改變而改變它的相關行為。典型的例子是一個人在不同的狀態下完成一件事的結果可能是不同的。

9.策略模式

• 定義

定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。

• 簡介

從策略模式的定義可以看到它主要是將演算法和客戶獨立開，一個典型的例子是排序演算法，我們給定一個數組，輸出排序後的結果，但是過程中我們可以採取不同的排序演算法，這些演算法其實就是策略。

10.責任鏈模式

• 定義

使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它為止。

• 簡介

責任鏈模式，避免請求傳送者與接收者耦合在一起，讓多個物件都有可能接收請求，將這些物件連線成一條鏈，並且沿著這條鏈傳遞請求，直到有物件處理它為止。

11.訪問者模式

• 定義

封裝一些作用於某種資料結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

• 簡介

訪問者模式是一種將資料操作和資料結構分離的設計模式，它通常使用在物件結構比較穩定，但是經常需要在此物件結構上定義新的操作，或者需要對一個物件結構中的物件進行很多不同的並且不相關的操作，而需要避免讓這些操作"汙染"這些物件的類，使用訪問者模式將這些封裝到類中

六.總結

到這裡，Java設計模式的學習總結就結束了，因為個人能力有限，有些模式只是簡單介紹了一下，想要進一步學習的話還是要靠大家自己去查閱相關資料學習。熟練地掌握設計模式，還需多多的實踐.

有完整的Java初級，高階對應的學習路線和資料！專注於java開發。分享java基礎、原理性知識、JavaWeb實戰、spring全家桶、設計模式、分散式及面試資料、開源專案，助力開發者成長！

歡迎關注微信公眾號：碼邦主