感覺設(shè)計(jì)模式是看著簡(jiǎn)單 ，但是一用就不會(huì)，23種設(shè)計(jì)模式，學(xué)的人頭大，相信大家都是這樣的

設(shè)計(jì)模式在程序員的面試中會(huì)被考到，通常是介紹其原理并說(shuō)出優(yōu)缺點(diǎn)?；蛘邔?duì)比幾個(gè)比較相似的模式的異同點(diǎn)。在筆試中可能會(huì)出現(xiàn)畫出某個(gè)設(shè)計(jì)模式的UML圖這樣的題。雖說(shuō)面試中占的比重不大，但并不代表它不重要。恰恰相反，設(shè)計(jì)模式于程序員而言相當(dāng)重要，它是我們寫出優(yōu)秀程序的保障。設(shè)計(jì)模式與程序員的架構(gòu)能力與閱讀源碼的能力息息相關(guān)，非常值得我們深入學(xué)習(xí)。

面向?qū)ο蟮耐倪@個(gè)小例子中只能看到冰山一角，好比一段兩公里的路程，坐飛機(jī)和走路花費(fèi)的時(shí)間差不了多少。但當(dāng)我們需要翻山越嶺、漂洋過(guò)海時(shí)，坐飛機(jī)的人就會(huì)將走路的人遠(yuǎn)遠(yuǎn)拋在后面。

面向?qū)ο蟮奶攸c(diǎn)是可維護(hù)、可復(fù)用、可擴(kuò)展、靈活性好，它真正強(qiáng)大的地方在于：隨著業(yè)務(wù)變得越來(lái)越復(fù)雜，面向?qū)ο笠廊荒軌蚴沟贸绦蚪Y(jié)構(gòu)良好，而面向過(guò)程卻會(huì)導(dǎo)致程序越來(lái)越臃腫。

讓面向?qū)ο蟊３纸Y(jié)構(gòu)良好的秘訣就是 設(shè)計(jì)模式。

熟練掌握各種設(shè)計(jì)模式，并能在實(shí)際編程開發(fā)中靈活運(yùn)用它們，不僅能使代碼更規(guī)范，重用性更高，同時(shí)也能保證代碼的可靠性，提高開發(fā)效率。這段時(shí)間又系統(tǒng)看了設(shè)計(jì)模式的相關(guān)內(nèi)容，
整理學(xué)習(xí)總結(jié)如下:

• 七個(gè)設(shè)計(jì)原則
• 創(chuàng)建型模式(5種)
• 結(jié)構(gòu)型模式(7種)
• 行為型模式(11種)

總體來(lái)說(shuō)設(shè)計(jì)模式分為三大類：(本文著重講解標(biāo)紅)
創(chuàng)建型模式，共五種： 工廠方法模式、 抽象工廠模式、 單例模式、 建造者模式、原型模式。
結(jié)構(gòu)型模式，共七種： 適配器模式、裝飾器模式、 代理模式、外觀模式、橋接模式、組合模式、 享元模式。
行為型模式，共十一種： 策略模式、模板方法模式、 觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式。

二.七個(gè)設(shè)計(jì)原則

面向?qū)ο缶幊逃衅叽笤瓌t，即經(jīng)常提到的Design Pattern，提倡它的根本原因是為了代碼復(fù)用，增加可維護(hù)性。設(shè)計(jì)模式就是實(shí)現(xiàn)了這些原則，從而達(dá)到了代碼復(fù)用、增加可維護(hù)性的目的。

因?yàn)樵O(shè)計(jì)模式就是基于這些原則的實(shí)現(xiàn)，所以很有必要了解這些原則，下面主要對(duì)面向?qū)ο缶幊痰膸讉€(gè)原則進(jìn)行簡(jiǎn)單介紹。

1、單一職責(zé)原則 ( SRP )

英文全稱是Single Responsibility Principle，定義是一個(gè)類，應(yīng)該只有一個(gè)引起它變化的原因。類變化的原因就是職責(zé)，如果一個(gè)類承擔(dān)的職責(zé)過(guò)多，就等于把這些職責(zé)耦合在一起了。一個(gè)職責(zé)的變化可能會(huì)削弱或者抑制這個(gè)類完成其他職責(zé)的能力。這種耦合會(huì)導(dǎo)致脆弱的設(shè)計(jì)，當(dāng)發(fā)生變化時(shí)，設(shè)計(jì)會(huì)遭受到意想不到的破壞。而如果想要避免這種現(xiàn)象的發(fā)生，就要盡可能的遵守單一職責(zé)原則。此原則的核心就是解耦和增強(qiáng)內(nèi)聚性。

2、開閉原則 ( OCP )
英文全稱是Open Close Principle，定義是軟件實(shí)體（包括類、模塊、函數(shù)等）應(yīng)該對(duì)于擴(kuò)展時(shí)開放的，對(duì)于修改是封閉的。開閉原則是是面向?qū)ο笤O(shè)計(jì)中最重要的原則之一，其它很多的設(shè)計(jì)原則都是實(shí)現(xiàn)開閉原則的一種手段。

3、里氏替換原則 ( LSP )
英文全稱是Liskov Substitution Principle，是面向?qū)ο笤O(shè)計(jì)的基本原則之一。 定義是任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。LSP 是繼承復(fù)用的基石，只有當(dāng)派生類可以替換掉基類，且軟件單位的功能不受到影響時(shí)，基類才能真正被復(fù)用，而派生類也能夠在基類的基礎(chǔ)上增加新的行為。里氏替換原則是對(duì)開閉原則的補(bǔ)充。實(shí)現(xiàn)開閉原則的關(guān)鍵步驟就是抽象化，而基類與子類的繼承關(guān)系就是抽象化的具體實(shí)現(xiàn)，所以里氏替換原則是對(duì)實(shí)現(xiàn)抽象化的具體步驟的規(guī)范。

4、依賴倒置原則 ( DIP )
英文全稱是Dependence Inversion Principle，這個(gè)原則是開閉原則的基礎(chǔ)，依賴倒置原則就是要求調(diào)用者和被調(diào)用者都依賴抽象，這樣兩者沒有直接的關(guān)聯(lián)和接觸，在變動(dòng)的時(shí)候，一方的變動(dòng)不會(huì)影響另一方的變動(dòng)。依賴倒置強(qiáng)調(diào)了抽象的重要性，針對(duì)接口編程，依賴于抽象而不依賴于具體。

5、接口隔離原則 ( ISP )
英文全稱是Interface Segregation Principle，這個(gè)原則的意思是使用多個(gè)隔離的接口，比使用單個(gè)接口要好。目的就是降低類之間的耦合度，便于軟件升級(jí)和維護(hù)。

6、最少知道原則(迪米特原則)
一個(gè)實(shí)體應(yīng)當(dāng)盡量少地與其他實(shí)體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對(duì)獨(dú)立。通俗地說(shuō)就是不要和陌生人說(shuō)話，即一個(gè)對(duì)象應(yīng)對(duì)其他對(duì)象有盡可能少的了解。迪米特法則的初衷在于降低類之間的耦合。由于每個(gè)類盡量減少對(duì)其他類的依賴，因此，很容易使得系統(tǒng)的功能模塊功能獨(dú)立，相互之間不存在（或很少有）依賴關(guān)系。

7、合成/聚合復(fù)用（CARP）
英文全稱是Composite Reuse Principle，合成/聚合復(fù)用原則經(jīng)常又叫做合成復(fù)用原則。合成/聚合復(fù)用原則的潛臺(tái)詞是：我只是用你的方法，我們不一定是同類。繼承的耦合性更大，比如一個(gè)父類后來(lái)添加實(shí)現(xiàn)一個(gè)接口或者去掉一個(gè)接口，那子類可能會(huì)遭到毀滅性的編譯錯(cuò)誤，但如果只是組合聚合，只是引用類的方法，就不會(huì)有這種巨大的風(fēng)險(xiǎn)，同時(shí)也實(shí)現(xiàn)了復(fù)用。

三.創(chuàng)建者模式(5種)

創(chuàng)建型模式是指這些設(shè)計(jì)模式提供了一種在創(chuàng)建對(duì)象的同時(shí)隱藏創(chuàng)建邏輯的方式，而不是使用新的運(yùn)算符直接實(shí)例化對(duì)象。這使得程序在判斷針對(duì)某個(gè)給定實(shí)例需要?jiǎng)?chuàng)建哪些對(duì)象時(shí)更加靈活

1.單例模式

• 定義

確保某一個(gè)類只有一個(gè)實(shí)例，并自行實(shí)例化向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。

• 簡(jiǎn)介

單例模式理解起來(lái)不難，典型例子有一個(gè)公司只能有一個(gè)CEO。它主要是為了保證一個(gè)類僅有一個(gè)實(shí)例，這個(gè)類中自己提供一個(gè)返回實(shí)例的方法，方法中先判斷系統(tǒng)是否已經(jīng)有這個(gè)單例，如果有則返回，如果沒有則創(chuàng)建。如果創(chuàng)建多個(gè)實(shí)例會(huì)消耗過(guò)多的資源或者某種類型的對(duì)象只應(yīng)該有且只有一個(gè)時(shí)，應(yīng)該考慮使用單例模式。

• 實(shí)現(xiàn)

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

public class Singleton {
// 直接創(chuàng)建對(duì)象
public static Singleton instance = new Singleton();
// 私有化構(gòu)造函數(shù)
private Singleton() {
}
// 返回對(duì)象實(shí)例
public static Singleton getInstance() {
return instance;
}
}

懶漢式:

//寫法一、懶漢式寫法

public class Singleton {
 
    private static Singleton instance; 

    //構(gòu)造函數(shù)私有
    private Singleton (){
    }  

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

//寫法二、DCL（Double Check Lock） 雙重校驗(yàn)鎖

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;  
    }  
} 
 

//寫法三、靜態(tài)內(nèi)部類單例模式

public class Singleton {  

    private Singleton (){
    }  

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

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

上面的第一種懶漢式寫法做到了延遲創(chuàng)建和線程安全，缺點(diǎn)是每次調(diào)用getInstance()時(shí)都必須進(jìn)行同步，效率不佳。第二種DCL方式比較常見，兩次判空，第一次判空避免了不必要的同步，第二次保證了單例創(chuàng)建，這種方式比較不錯(cuò)，但是在高并發(fā)環(huán)境下有時(shí)會(huì)出現(xiàn)問題。第三種方法最被推薦，線程安全也保證了實(shí)例唯一。

2.工廠方法模式

• 定義

定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類。

工廠方法模式分為三種：普通工廠模式，就是建立一個(gè)工廠類，對(duì)實(shí)現(xiàn)了同一接口的一些類進(jìn)行實(shí)例的創(chuàng)建。多個(gè)工廠方法模式，是對(duì)普通工廠方法模式的改進(jìn)，在普通工廠方法模式中，如果傳遞的字符串出錯(cuò)，則不能正確創(chuàng)建對(duì)象，而多個(gè)工廠方法模式是提供多個(gè)工廠方法，分別創(chuàng)建對(duì)象。靜態(tài)工廠方法模式，將上面的多個(gè)工廠方法模式里的方法置為靜態(tài)的，不需要?jiǎng)?chuàng)建實(shí)例，直接調(diào)用即可 .

(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("請(qǐng)輸入正確的類型!");
return null;
}
}
}

(2)多個(gè)工廠模式

該模式是對(duì)普通工廠方法模式的改進(jìn)，在普通工廠方法模式中，如果傳遞的字符串出錯(cuò)，則不能正確創(chuàng)建對(duì)象，而多個(gè)工廠方法模式是提供多個(gè)工廠方法，分別創(chuàng)建對(duì)象。

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)靜態(tài)工廠模式

靜態(tài)工廠方法模式，將上面的多個(gè)工廠方法模式里的方法置為靜態(tài)的，不需要?jiǎng)?chuàng)建實(shí)例，直接調(diào)用即可

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.抽象工廠模式

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

代碼還是在工廠方法模式的基礎(chǔ)上改進(jìn)

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 )

工廠類模式提供的是創(chuàng)建單個(gè)類的模式，而建造者模式則是將各種產(chǎn)品集中起來(lái)進(jìn)行管理，用來(lái)創(chuàng)建復(fù)合對(duì)象，所謂復(fù)合對(duì)象就是指某個(gè)類具有不同的屬性，其實(shí)建造者模式就是前面抽象工廠模式和最后的 Test 結(jié)合起來(lái)得到的

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.原型模式

• 定義

用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過(guò)拷貝這些原型創(chuàng)建新的對(duì)象。

• 簡(jiǎn)介

原型模式不難理解，它主要是用在實(shí)例創(chuàng)建的時(shí)候，因?yàn)橛械臅r(shí)候我們通過(guò)new創(chuàng)建一個(gè)對(duì)象時(shí)可能成本過(guò)高，這時(shí)我們可以考慮直接通過(guò)直接克隆實(shí)例快速創(chuàng)建對(duì)象?？寺『蟮膶?shí)例與原實(shí)例內(nèi)部屬性一致。原型模式需要注意一個(gè)深拷貝和淺拷貝的問題。
四.結(jié)構(gòu)型模式(7種)
結(jié)構(gòu)型模式關(guān)注類和對(duì)象的組合。繼承的概念被用來(lái)組合接口和定義組合對(duì)象獲得新功能的方式。

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

適配器模式將某個(gè)類的接口轉(zhuǎn)換成客戶端期望的另一個(gè)接口表示，目的是消除由于接口不匹配所造成的類的兼容性問題。主要分為三類：類的適配器模式、對(duì)象的適配器模式、接口的適配器模式

• 類的適配器模式

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();
 }
}

• 對(duì)象的適配器模式

基本思路和類的適配器模式相同，只是將 Adapter 類作修改，這次不繼承 Source 類，而是持有 Source 類的實(shí)例，以達(dá)到解決兼容性的問題

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();
}
}

• 接口的適配器模式

接口的適配器是這樣的：有時(shí)我們寫的一個(gè)接口中有多個(gè)抽象方法，當(dāng)我們寫該接口的實(shí)現(xiàn)類時(shí)，必須實(shí)現(xiàn)該接口的所有方法，這明顯有時(shí)比較浪費(fèi)，因?yàn)椴⒉皇撬械姆椒ǘ际俏覀冃枰?，有時(shí)只需要某一些，此處為了解決這個(gè)問題，我們引入了接口的適配器模式，借助于一個(gè)抽象類，該抽象類實(shí)現(xiàn)了該接口，實(shí)現(xiàn)了所有的方法，而我們不和原始的接口打交道，只和該抽象類取得聯(lián)系，所以我們寫一個(gè)類，繼承該抽象類，重寫我們需要的方法就行。

2.橋接模式

• 定義

將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化。

• 簡(jiǎn)介

在軟件系統(tǒng)中，某些類型由于自身的邏輯，它具有兩個(gè)或多個(gè)維度的變化，那么如何應(yīng)對(duì)這種“多維度的變化”？這就要使用橋接模式。橋接模式需要重點(diǎn)理解的抽象部分，實(shí)現(xiàn)部分，脫耦。一個(gè)典型的例子是咖啡加糖問題，抽象部分有Coffee，其下有LargeCoffee，SmallCoffee，實(shí)現(xiàn)部分是CoffeeAdd，其下有Sugar，Normal，抽象類Coffee中引用CoffeeAdd，這樣CoffeeAdd其實(shí)就是一個(gè)橋接。

3.裝飾模式
顧名思義，裝飾模式就是給一個(gè)對(duì)象增加一些新的功能，而且是動(dòng)態(tài)的，要求裝飾對(duì)象和被裝飾對(duì)象實(shí)現(xiàn)同一個(gè) 接口，裝飾對(duì)象持有被裝飾對(duì)象的實(shí)例。

4.組合模式

• 定義

將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。

• 簡(jiǎn)介

組合模式理解起來(lái)相對(duì)簡(jiǎn)單，典型的例子就是假設(shè)公司A，里面有不同的部門，不同的部分下有不同的員工，這樣一個(gè)部門下的所有員工組合成了一個(gè)部門，所有部門組合成了整個(gè)公司。

5.外觀模式

• 定義

為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，外觀模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。

• 簡(jiǎn)介

外觀模式的一個(gè)典型例子是去醫(yī)院看病，掛號(hào)、門診、劃價(jià)、取藥，讓患者或患者家屬覺得很復(fù)雜，如果有提供接待人員，只讓接待人員來(lái)處理，就很方便。

6.享元模式

• 定義

運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。

• 簡(jiǎn)介

在有大量對(duì)象時(shí)，有可能會(huì)造成內(nèi)存溢出，我們把其中共同的部分抽象出來(lái)，如果有相同的業(yè)務(wù)請(qǐng)求，直接返回在內(nèi)存中已有的對(duì)象，避免重新創(chuàng)建。

7.代理模式

• 定義

為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問。

• 簡(jiǎn)介

代理模式主要解決在直接訪問對(duì)象時(shí)帶來(lái)的問題。舉個(gè)例子，豬八戒去找高翠蘭結(jié)果是孫悟空變的，可以這樣理解：把高翠蘭的外貌抽象出來(lái)，高翠蘭本人和孫悟空都實(shí)現(xiàn)了這個(gè)接口，豬八戒訪問高翠蘭的時(shí)候看不出來(lái)這個(gè)是孫悟空，所以說(shuō)孫悟空是高翠蘭代理類。

五、行為型模式 ( 11種 )

這些設(shè)計(jì)模式特別關(guān)注對(duì)象之間的通信。

1.模板方法模式

• 定義

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

• 例子

模板方法模式一個(gè)典型例子就是Android中的異步任務(wù)類AsyncTask，它對(duì)異步任務(wù)的執(zhí)行進(jìn)行了流程封裝，子類繼承它時(shí)，只需在指定的流程中實(shí)現(xiàn)具體的操作即可。

2.命令模式

• 定義

將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可取消的操作

• 簡(jiǎn)介

命令模式主要是通過(guò)調(diào)用者調(diào)用接受者執(zhí)行命令，這個(gè)模式中需要理解的是三個(gè)角色：(1) Receiver 真正的命令執(zhí)行對(duì)象 (2) Command 持有一個(gè)對(duì)Receiver的引用，調(diào)用Receiver的相關(guān)方法。(3) Invoker 請(qǐng)求者，持有一個(gè)對(duì)Command的引用，調(diào)用Command的方法執(zhí)行具體命令。

3.迭代器模式

• 定義

提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素, 而又不需暴露該對(duì)象的內(nèi)部表示。

• 簡(jiǎn)介

在Java集合框架中我們知道對(duì)于一個(gè)指定的集合類，我們可以使用一個(gè)特定的Iterator迭代器來(lái)對(duì)集合中的所有元素進(jìn)行遍歷。這樣結(jié)合來(lái)看，迭代器模式很好理解了。

4.觀察者模式

• 定義

定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。

• 簡(jiǎn)介

觀察者模式可以結(jié)合Android中的ListView來(lái)理解，ListView關(guān)聯(lián)的適配器Adapter在數(shù)據(jù)發(fā)生變化時(shí)會(huì)通過(guò)notifyDataSetChanged()方法來(lái)通知界面刷新。

5.中介者模式

• 定義

用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。

• 簡(jiǎn)介

中介者模式的典型例子就是未加入 WTO 之前各個(gè)國(guó)家相互貿(mào)易，結(jié)構(gòu)復(fù)雜，大家都加入WTO后是各個(gè)國(guó)家通過(guò) WTO 來(lái)互相貿(mào)易，變得規(guī)范。

6.備忘錄模式

• 定義

在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到保存的狀態(tài)。

• 簡(jiǎn)介

備忘錄模式的典型例子就是git版本管理工具，它幫我們保存了每次提交后的項(xiàng)目狀態(tài)，在必要的時(shí)候我們可以回退到指定的版本中。

7.解釋器模式

• 定義

給定一個(gè)語(yǔ)言，定義它的文法的一種表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。

• 簡(jiǎn)介

解釋器的典型例子是在編譯原理中的應(yīng)用，如果一種特定類型的問題發(fā)生的頻率足夠高，那么可能就值得將該問題的各個(gè)實(shí)例表述為一個(gè)簡(jiǎn)單語(yǔ)言中的句子。這樣就可以構(gòu)建一個(gè)解釋器，該解釋器通過(guò)解釋這些句子來(lái)解決該問題。

8.狀態(tài)模式

• 定義

允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來(lái)似乎修改了它的類。

• 簡(jiǎn)介

狀態(tài)模式主要解決對(duì)象的行為依賴于它的狀態(tài)（屬性），并且可以根據(jù)它的狀態(tài)改變而改變它的相關(guān)行為。典型的例子是一個(gè)人在不同的狀態(tài)下完成一件事的結(jié)果可能是不同的。

9.策略模式

• 定義

定義一系列的算法,把它們一個(gè)個(gè)封裝起來(lái), 并且使它們可相互替換。本模式使得算法可獨(dú)立于使用它的客戶而變化。

• 簡(jiǎn)介

從策略模式的定義可以看到它主要是將算法和客戶獨(dú)立開，一個(gè)典型的例子是排序算法，我們給定一個(gè)數(shù)組，輸出排序后的結(jié)果，但是過(guò)程中我們可以采取不同的排序算法，這些算法其實(shí)就是策略。

10.責(zé)任鏈模式

• 定義

使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免請(qǐng)求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，直到有一個(gè)對(duì)象處理它為止。

• 簡(jiǎn)介

責(zé)任鏈模式，避免請(qǐng)求發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有可能接收請(qǐng)求，將這些對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有對(duì)象處理它為止。

11.訪問者模式

• 定義

封裝一些作用于某種數(shù)據(jù)結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

• 簡(jiǎn)介

訪問者模式是一種將數(shù)據(jù)操作和數(shù)據(jù)結(jié)構(gòu)分離的設(shè)計(jì)模式，它通常使用在對(duì)象結(jié)構(gòu)比較穩(wěn)定，但是經(jīng)常需要在此對(duì)象結(jié)構(gòu)上定義新的操作，或者需要對(duì)一個(gè)對(duì)象結(jié)構(gòu)中的對(duì)象進(jìn)行很多不同的并且不相關(guān)的操作，而需要避免讓這些操作"污染"這些對(duì)象的類，使用訪問者模式將這些封裝到類中

六.總結(jié)

到這里，Java設(shè)計(jì)模式的學(xué)習(xí)總結(jié)就結(jié)束了，因?yàn)閭€(gè)人能力有限，有些模式只是簡(jiǎn)單介紹了一下，想要進(jìn)一步學(xué)習(xí)的話還是要靠大家自己去查閱相關(guān)資料學(xué)習(xí)。熟練地掌握設(shè)計(jì)模式，還需多多的實(shí)踐.

有完整的Java初級(jí)，高級(jí)對(duì)應(yīng)的學(xué)習(xí)路線和資料！專注于java開發(fā)。分享java基礎(chǔ)、原理性知識(shí)、JavaWeb實(shí)戰(zhàn)、spring全家桶、設(shè)計(jì)模式、分布式及面試資料、開源項(xiàng)目，助力開發(fā)者成長(zhǎng)！

歡迎關(guān)注微信公眾號(hào)：碼邦主