我們平時(shí)使用的每一個(gè)技術(shù)棧的原理或者源碼都或多或少與設(shè)計(jì)模式的理念有關(guān)聯(lián)，也可以這么說(shuō)，只有更好的掌握了設(shè)計(jì)模式，我們的代碼編寫才能更規(guī)范、簡(jiǎn)潔，效率更高。

其次，設(shè)計(jì)模式大多都是經(jīng)過(guò)我們的前輩的經(jīng)驗(yàn)反復(fù)總結(jié)而成，站在巨人的肩膀上，吸收他們的經(jīng)驗(yàn)教訓(xùn)，我們的編碼之路才會(huì)走的更長(zhǎng)久。

同時(shí)，在我們的面試過(guò)程中也是加分的選項(xiàng)，你如果將設(shè)計(jì)模式能跟面試官娓娓道來(lái)，面試官肯定會(huì)對(duì)你刮目相看的。工作中，擁有良好的設(shè)計(jì)模式思想，對(duì)于項(xiàng)目的開(kāi)發(fā)也會(huì)有很大的幫助。

接下來(lái)，跟著小羽一起來(lái)看看我們需要了解的設(shè)計(jì)模式都有哪些呢～

前言

總體來(lái)說(shuō)設(shè)計(jì)模式分為三大類：

創(chuàng)建型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結(jié)構(gòu)型模式：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問(wèn)者模式、中介者模式、解釋器模式。

單例模式

概念

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

使用場(chǎng)景

• 要求生成唯一序列號(hào)的環(huán)境；

• 在整個(gè)項(xiàng)目中需要一個(gè)共享訪問(wèn)點(diǎn)或共享數(shù)據(jù)，例如一個(gè)Web頁(yè)面上的計(jì)數(shù)器，可以不用把每次刷新都記錄到數(shù)據(jù)庫(kù)中，使用單例模式保持計(jì)數(shù)器的值，并確保是線程安全的；

• 創(chuàng)建一個(gè)對(duì)象需要消耗的資源過(guò)多，如要訪問(wèn)IO和數(shù)據(jù)庫(kù)等資源；

• 需要定義大量的靜態(tài)常量和靜態(tài)方法（如工具類）的環(huán)境，可以采用單例模式（當(dāng)然，也可以直接聲明為static的方式）。

代碼示例

線程安全：

public class Singleton {
    private static final Singleton singleton = new Singleton();
    //限制產(chǎn)生多個(gè)對(duì)象
    private Singleton(){
    }
    //通過(guò)該方法獲得實(shí)例對(duì)象
    public static Singleton getSingleton(){
        return singleton;
    }
    //類中其他方法，盡量是 static
    public static void doSomething(){
    }
}

線程不安全：

public class Singleton {
    private static Singleton singleton = null;
    //限制產(chǎn)生多個(gè)對(duì)象
    private Singleton(){
    }
    //通過(guò)該方法獲得實(shí)例對(duì)象
    public static Singleton getSingleton(){
        if(singleton == null){
            singleton = new Singleton();
        }
        return singleton;
    }
}

工廠模式

概念

定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類。工廠方法使一個(gè)類的實(shí)例化延遲到其子類。

使用場(chǎng)景

jdbc 連接數(shù)據(jù)庫(kù)，硬件訪問(wèn)，降低對(duì)象的產(chǎn)生和銷毀

結(jié)構(gòu)

簡(jiǎn)單工廠模式：一個(gè)模塊僅需要一個(gè)工廠類，沒(méi)有必要把它產(chǎn)生出來(lái)，使用靜態(tài)的方法

多個(gè)工廠類：每個(gè)人種（具體的產(chǎn)品類）都對(duì)應(yīng)了一個(gè)創(chuàng)建者，每個(gè)創(chuàng)建者獨(dú)立負(fù)責(zé)創(chuàng)建對(duì)應(yīng)的產(chǎn)品對(duì)象，非常符合單一職責(zé)原則

代替單例模式：單例模式的核心要求就是在內(nèi)存中只有一個(gè)對(duì)象，通過(guò)工廠方法模式也可以只在內(nèi)存中生產(chǎn)一個(gè)對(duì)象

延遲初始化：ProductFactory 負(fù)責(zé)產(chǎn)品類對(duì)象的創(chuàng)建工作，并且通過(guò) prMap 變量產(chǎn)生一個(gè)緩存，對(duì)需要再次被重用的對(duì)象保留

代碼示例

Product 為抽象產(chǎn)品類負(fù)責(zé)定義產(chǎn)品的共性，實(shí)現(xiàn)對(duì)事物最抽象的定義；

Creator 為抽象創(chuàng)建類，也就是抽象工廠，具體如何創(chuàng)建產(chǎn)品類是由具體的實(shí)現(xiàn)工廠 ConcreteCreator 完成的。

public class ConcreteCreator extends Creator {
    public <T extends Product> T createProduct(Class<T> c){
        Product product=null;
        try {
            product =
                    (Product)Class.forName(c.getName()).newInstance();
        } catch (Exception e) {
        //異常處理
        }
        return (T)product;
    }
}

抽象工廠模式

概念

為創(chuàng)建一組相關(guān)或相互依賴的對(duì)象提供一個(gè)接口，而且無(wú)須指定它們的具體類。

使用場(chǎng)景

一個(gè)對(duì)象族（或是一組沒(méi)有任何關(guān)系的對(duì)象）都有相同的約束。

涉及不同操作系統(tǒng)的時(shí)候，都可以考慮使用抽象工廠模式。

代碼示例

public abstract class AbstractCreator {
    //創(chuàng)建 A 產(chǎn)品家族
    public abstract AbstractProductA createProductA();
    //創(chuàng)建 B 產(chǎn)品家族
    public abstract AbstractProductB createProductB();
}

模板方法模式

概念

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

使用場(chǎng)景

• 多個(gè)子類有公有的方法，并且邏輯基本相同時(shí)。

• 重要、復(fù)雜的算法，可以把核心算法設(shè)計(jì)為模板方法，周邊的相關(guān)細(xì)節(jié)功能則由各個(gè)子類實(shí)現(xiàn)。

• 重構(gòu)時(shí)，模板方法模式是一個(gè)經(jīng)常使用的模式，把相同的代碼抽取到父類中，然后通過(guò)鉤子函數(shù)（見(jiàn)“模板方法模式的擴(kuò)展”）約束其行為。

結(jié)構(gòu)

抽象模板：AbstractClass 為抽象模板，它的方法分為兩類：

1、基本方法：也叫做基本操作，是由子類實(shí)現(xiàn)的方法，并且在模板方法被調(diào)用。

2、模板方法：可以有一個(gè)或幾個(gè)，一般是一個(gè)具體方法，也就是一個(gè)框架，實(shí)現(xiàn)對(duì)基本方法的調(diào)度，完成固定的邏輯。

注意： 為了防止惡意的操作，一般模板方法都加上 final 關(guān)鍵字，不允許被覆寫。

具體模板：實(shí)現(xiàn)父類所定義的一個(gè)或多個(gè)抽象方法，也就是父類定義的基本方法在子類中得以實(shí)現(xiàn)。

代碼示例

package templateMethod;
public class TemplateMethodPattern
{
    public static void main(String[] args)
    {
        AbstractClass tm=new ConcreteClass();
        tm.TemplateMethod();
    }
}

//抽象類
abstract class AbstractClass
{
    public void TemplateMethod() //模板方法
    {
        SpecificMethod();
        abstractMethod1();
        abstractMethod2();
    }
    public void SpecificMethod() //具體方法
    {
        System.out.println("抽象類中的具體方法被調(diào)用...");
    }
    public abstract void abstractMethod1(); //抽象方法1
    public abstract void abstractMethod2(); //抽象方法2
}

//具體子類
class ConcreteClass extends AbstractClass
{
    public void abstractMethod1()
    {
        System.out.println("抽象方法1的實(shí)現(xiàn)被調(diào)用...");
    }
    public void abstractMethod2()
    {
        System.out.println("抽象方法2的實(shí)現(xiàn)被調(diào)用...");
    }
}

建造者模式

概念

將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。

使用場(chǎng)景

• 相同的方法，不同的執(zhí)行順序，產(chǎn)生不同的事件結(jié)果時(shí)，可以采用建造者模式。

• 多個(gè)部件或零件，都可以裝配到一個(gè)對(duì)象中，但是產(chǎn)生的運(yùn)行結(jié)果又不相同時(shí)，則可以使用該模式。

• 產(chǎn)品類非常復(fù)雜，或者產(chǎn)品類中的調(diào)用順序不同產(chǎn)生了不同的效能，這個(gè)時(shí)候使用建造者模式非常合適。

結(jié)構(gòu)

Product 產(chǎn)品類：通常是實(shí)現(xiàn)了模板方法模式，也就是有模板方法和基本方法。

Builder 抽象建造者：規(guī)范產(chǎn)品的組建，一般是由子類實(shí)現(xiàn)。

ConcreteBuilder 具體建造者：實(shí)現(xiàn)抽象類定義的所有方法，并且返回一個(gè)組建好的對(duì)象。

Director 導(dǎo)演類：負(fù)責(zé)安排已有模塊的順序，然后告訴 Builder 開(kāi)始建造

代碼示例

public class ConcreteProduct extends Builder {
     private Product product = new Product();
     //設(shè)置產(chǎn)品零件
     public void setPart(){
             /*
              * 產(chǎn)品類內(nèi)的邏輯處理
              */
     }  
     //組建一個(gè)產(chǎn)品
     public Product buildProduct() {
             return product;
     }
}

代理模式

概念

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

結(jié)構(gòu)

Subject 抽象主題角色：抽象主題類可以是抽象類也可以是接口，是一個(gè)最普通的業(yè)務(wù)類型定義，無(wú)特殊要求。

RealSubject 具體主題角色：也叫做被委托角色、被代理角色。它才是冤大頭，是業(yè)務(wù)邏輯的具體執(zhí)行者。

Proxy 代理主題角色：也叫做委托類、代理類。它負(fù)責(zé)對(duì)真實(shí)角色的應(yīng)用，把所有抽象主題類定義的方法、限制委托給真實(shí)主題角色實(shí)現(xiàn)，并且在真實(shí)主題角色處理完畢前后做預(yù)處理和善后處理工作。

分類

普通代理：在該模式下，調(diào)用者只知代理而不用知道真實(shí)的角色是誰(shuí)，屏蔽了真實(shí)角色的變更對(duì)高層模塊的影響，真實(shí)的主題角色想怎么修改就怎么修改，對(duì)高層次的模塊沒(méi)有任何的影響，只要你實(shí)現(xiàn)了接口所對(duì)應(yīng)的方法，該模式非常適合對(duì)擴(kuò)展性要求較高的場(chǎng)合。

強(qiáng)制代理：強(qiáng)制代理的概念就是要從真實(shí)角色查找到代理角色，不允許直接訪問(wèn)真實(shí)角色。高層模塊只要調(diào)用 getProxy 就可以訪問(wèn)真實(shí)角色的所有方法，它根本就不需要產(chǎn)生一個(gè)代理出來(lái)，代理的管理已經(jīng)由真實(shí)角色自己完成。

• 區(qū)別：普通代理就是我們要知道代理的存在，然后才能訪問(wèn)；強(qiáng)制代理則是調(diào)用者直接調(diào)用真實(shí)角色，而不用關(guān)心代理是否存在，其代理的產(chǎn)生是由真實(shí)角色決定的。

動(dòng)態(tài)代理：根據(jù)被代理的接口生成所有的方法，也就是說(shuō)給定一個(gè)接口，動(dòng)態(tài)代理會(huì)宣稱“我已經(jīng)實(shí)現(xiàn)該接口下的所有方法了”。兩條獨(dú)立發(fā)展的線路。動(dòng)態(tài)代理實(shí)現(xiàn)代理的職責(zé)，業(yè)務(wù)邏輯實(shí)現(xiàn)相關(guān)的邏輯功能，兩者之間沒(méi)有必然的相互耦合的關(guān)系。通知從另一個(gè)切面切入，最終在高層模塊進(jìn)行耦合，完成邏輯的封裝任務(wù)。

• 意圖：橫切面編程，在不改變我們已有代碼結(jié)構(gòu)的情況下增強(qiáng)或控制對(duì)象的行為。

• 首要條件：被代理的類必須要實(shí)現(xiàn)一個(gè)接口。

代碼示例

public Object getProxy(@Nullable ClassLoader classLoader) {
    if (logger.isTraceEnabled()) {
        logger.trace("Creating JDK dynamic proxy: " + this.advised.getTargetSource());
    }
    Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
    findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
    return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}

原型模式

概念

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

使用場(chǎng)景

資源優(yōu)化場(chǎng)景：類初始化需要消化非常多的資源，這個(gè)資源包括數(shù)據(jù)、硬件資源等。

性能和安全要求的場(chǎng)景：通過(guò) new 產(chǎn)生一個(gè)對(duì)象需要非常繁瑣的數(shù)據(jù)準(zhǔn)備或訪問(wèn)權(quán)限，則可以使用原型模式。

一個(gè)對(duì)象多個(gè)修改者的場(chǎng)景：一個(gè)對(duì)象需要提供給其他對(duì)象訪問(wèn)，而且各個(gè)調(diào)用者可能都需要修改其值時(shí)，可以、考慮使用原型模式拷貝多個(gè)對(duì)象供調(diào)用者使用。

優(yōu)點(diǎn)

原型模式實(shí)際上就是實(shí)現(xiàn) Cloneable 接口，重寫 clone（）方法。

性能優(yōu)良：原型模式是在內(nèi)存二進(jìn)制流的拷貝，要比直接 new 一個(gè)對(duì)象性能好很多，特別是要在一個(gè)循環(huán)體內(nèi)產(chǎn)生大量的對(duì)象時(shí)，原型模式可以更好地體現(xiàn)其優(yōu)點(diǎn)。

逃避構(gòu)造函數(shù)的約束：這既是它的優(yōu)點(diǎn)也是缺點(diǎn)，直接在內(nèi)存中拷貝，構(gòu)造函數(shù)是不會(huì)執(zhí)行的。

代碼示例

public class PrototypeClass implements Cloneable{
    //覆寫父類 Object 方法
    @Override
    public PrototypeClass clone(){
        PrototypeClass prototypeClass = null;
        try {
            prototypeClass = (PrototypeClass)super.clone();
        } catch (CloneNotSupportedException e) {
        //異常處理
        }
        return prototypeClass;
    }
}

中介者模式

概念

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

使用場(chǎng)景

中介者模式適用于多個(gè)對(duì)象之間緊密耦合的情況，緊密耦合的標(biāo)準(zhǔn)是：在類圖中出現(xiàn)了蜘蛛網(wǎng)狀結(jié)構(gòu)，即每個(gè)類都與其他的類有直接的聯(lián)系。

結(jié)構(gòu)

Mediator 抽象中介者角色：抽象中介者角色定義統(tǒng)一的接口，用于各同事角色之間的通信。

Concrete Mediator 具體中介者角色：具體中介者角色通過(guò)協(xié)調(diào)各同事角色實(shí)現(xiàn)協(xié)作行為，因此它必須依賴于各個(gè)同事角色。

Colleague 同事角色：每一個(gè)同事角色都知道中介者角色，而且與其他的同事角色通信的時(shí)候，一定要通過(guò)中介者角色協(xié)作。每個(gè)同事類的行為分為兩種：一種是同事本身的行為，比如改變對(duì)象本身的狀態(tài)，處理自己的行為等，這種行為叫做自發(fā)行為（SelfMethod），與其他的同事類或中介者沒(méi)有任何的依賴；第二種是必須依賴中介者才能完成的行為，叫做依賴方法（Dep-Method）。

示例代碼

public abstract class Mediator {
    //定義同事類
    protected ConcreteColleague1 c1;
    protected ConcreteColleague2 c2;
    //通過(guò) getter/setter 方法把同事類注入進(jìn)來(lái)
    public ConcreteColleague1 getC1() {
        return c1;
    }
    public void setC1(ConcreteColleague1 c1) {
        this.c1 = c1;
    }
    public ConcreteColleague2 getC2() {
        return c2;
    }
    public void setC2(ConcreteColleague2 c2) {
        this.c2 = c2;
    }
    //中介者模式的業(yè)務(wù)邏輯
    public abstract void doSomething1();
    public abstract void doSomething2();
}

命令模式

概念

將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象，從而讓你使用不同的請(qǐng)求把客戶端參數(shù)化，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，可以提供命令的撤銷和恢復(fù)功能。

使用場(chǎng)景

認(rèn)為是命令的地方就可以采用命令模式，例如，在 GUI 開(kāi)發(fā)中，一個(gè)按鈕的點(diǎn)擊是一個(gè)命令，可以采用命令模式；模擬 DOS 命令的時(shí)候，當(dāng)然也要采用命令模式；觸發(fā)－反饋機(jī)制的處理等。

結(jié)構(gòu)

Receive 接收者角色：該角色就是干活的角色，命令傳遞到這里是應(yīng)該被執(zhí)行的，具體到我們上面的例子中就是 Group 的三個(gè)實(shí)現(xiàn)類（需求組，美工組，代碼組）。

Command 命令角色：需要執(zhí)行的所有命令都在這里聲明。

Invoker 調(diào)用者角色：接收到命令，并執(zhí)行命令。在例子中，我（項(xiàng)目經(jīng)理）就是這個(gè)角色。

代碼示例

public class Invoker {
    private Command command;

    // 設(shè)值注入
    public void setCommand(Command command) {
        this.command = command;
    }

    // 執(zhí)行命令
    public void action() {
        this.command.execute();
    }
}

責(zé)任鏈模式

概念

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

職責(zé)

抽象的處理者實(shí)現(xiàn)三個(gè)職責(zé)：

1、定義一個(gè)請(qǐng)求的處理方法 handleMessage，唯一對(duì)外開(kāi)放的方法；

2、定義一個(gè)鏈的編排方法 setNext，設(shè)置下一個(gè)處理者；

3、定義了具體的請(qǐng)求者必須實(shí)現(xiàn)的兩個(gè)方法：定義自己能夠處理的級(jí)別getHandlerLevel 和具體的處理任務(wù) echo。

代碼示例

public abstract class Handler {
    private Handler nextHandler;
    //每個(gè)處理者都必須對(duì)請(qǐng)求做出處理
    public final Response handleMessage(Request request){
        Response response = null;
        //判斷是否是自己的處理級(jí)別
        if(this.getHandlerLevel().equals(request.getRequestLevel())){
            response = this.echo(request);
        }else{ //不屬于自己的處理級(jí)別
            //判斷是否有下一個(gè)處理者
            if(this.nextHandler != null){
                response =
                        this.nextHandler.handleMessage(request);
            }else{
            //沒(méi)有適當(dāng)?shù)奶幚碚?，業(yè)務(wù)自行處理
            } }
        return response;
    }
    //設(shè)置下一個(gè)處理者是誰(shuí)
    public void setNext(Handler _handler){
        this.nextHandler = _handler;
    }
    //每個(gè)處理者都有一個(gè)處理級(jí)別
    protected abstract Level getHandlerLevel();
    //每個(gè)處理者都必須實(shí)現(xiàn)處理任務(wù)
    protected abstract Response echo(Request request);
}

注意事項(xiàng)

鏈中節(jié)點(diǎn)數(shù)量需要控制，避免出現(xiàn)超長(zhǎng)鏈的情況，一般的做法是在 Handler 中設(shè)置一個(gè)最大節(jié)點(diǎn)數(shù)量，在 setNext 方法中判斷是否已經(jīng)是超過(guò)其閾值，超過(guò)則不允許該鏈建立，避免無(wú)意識(shí)地破壞系統(tǒng)性能。

裝飾模式

概念

動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就增加功能來(lái)說(shuō)，裝飾模式相比生成子類更為靈活。

使用場(chǎng)景

• 需要擴(kuò)展一個(gè)類的功能，或給一個(gè)類增加附加功能。

• 需要?jiǎng)討B(tài)地給一個(gè)對(duì)象增加功能，這些功能可以再動(dòng)態(tài)地撤銷。

• 需要為一批的兄弟類進(jìn)行改裝或加裝功能，當(dāng)然是首選裝飾模式。

結(jié)構(gòu)

Component 抽象構(gòu)件：Component 是一個(gè)接口或者是抽象類，就是定義我們最核心的對(duì)象，也就是最原始的對(duì)象。在裝飾模式中，必然有一個(gè)最基本、最核心、最原始的接口或抽象類充當(dāng)Component 抽象構(gòu)件。

ConcreteComponent 具體構(gòu)件：ConcreteComponent 是最核心、最原始、最基本的接口或抽象類的實(shí)現(xiàn)，你要裝飾的就是它。

Decorator 裝飾角色：一般是一個(gè)抽象類，做什么用呢？實(shí)現(xiàn)接口或者抽象方法，它里面可不一定有抽象的方法呀，在它的屬性里必然有一個(gè) private 變量指向 Component 抽象構(gòu)件。

具體裝飾角色：兩個(gè)具體的裝飾類，你要把你最核心的、最原始的、最基本的東西裝飾成其他東西。

代碼示例

/**
 * 裝飾角色
 */
@Data
@AllArgsConstructor
@NoArgsConstructor
@Log
class BufferedReader implements Reader{

    private  Reader reader;
    @Override
    public void read() {
        reader.read();
    }

    public void readLine(){
        read();
        log.info("并且僅僅讀取一行");
    }
}

策略模式

概念

定義一組算法，將每個(gè)算法都封裝起來(lái)，并且使它們之間可以互換。

使用場(chǎng)景

• 多個(gè)類只有在算法或行為上稍有不同的場(chǎng)景。

• 算法需要自由切換的場(chǎng)景。

• 需要屏蔽算法規(guī)則的場(chǎng)景。

• 具體策略數(shù)量超過(guò) 4 個(gè)，則需要考慮使用混合模式

結(jié)構(gòu)

Context 封裝角色：它也叫做上下文角色，起承上啟下封裝作用，屏蔽高層模塊對(duì)策略、算法的直接訪問(wèn)，封裝可能存在的變化。

Strategy 抽象策略角色：策略、算法家族的抽象，通常為接口，定義每個(gè)策略或算法必須具有的方法和屬性。

ConcreteStrategy 具體策略角色：實(shí)現(xiàn)抽象策略中的操作，該類含有具體的算法。

代碼示例

public enum Calculator {
    //加法運(yùn)算
    ADD("+"){
        public int exec(int a,int b){
            return a+b;
        }
    },
    //減法運(yùn)算
    SUB("-"){
        public int exec(int a,int b){
            return a - b;
        }
    };
    String value = "";
    //定義成員值類型
    private Calculator(String _value){
        this.value = _value;
    }
    //獲得枚舉成員的值
    public String getValue(){
        return this.value;
    }
    //聲明一個(gè)抽象函數(shù)
    public abstract int exec(int a,int b);
}

適配器模式

概念

將一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無(wú)法在一起工作的兩個(gè)類能夠在一起工作。

使用場(chǎng)景

你有動(dòng)機(jī)修改一個(gè)已經(jīng)投產(chǎn)中的接口時(shí)，適配器模式可能是最適合你的模式。比如系統(tǒng)擴(kuò)展了，需要使用一個(gè)已有或新建立的類，但這個(gè)類又不符合系統(tǒng)的接口，怎么辦？詳細(xì)設(shè)計(jì)階段不要考慮使用適配器模式，使用主要場(chǎng)景為擴(kuò)展應(yīng)用中。

類適配器

Target 目標(biāo)角色：該角色定義把其他類轉(zhuǎn)換為何種接口，也就是我們的期望接口。

Adaptee 源角色：你想把誰(shuí)轉(zhuǎn)換成目標(biāo)角色，這個(gè)“誰(shuí)”就是源角色，它是已經(jīng)存在的、運(yùn)行良好的類或?qū)ο螅?jīng)過(guò)適配器角色的包裝，它會(huì)成為一個(gè)嶄新、靚麗的角色。

Adapter 適配器角色：適配器模式的核心角色，其他兩個(gè)角色都是已經(jīng)存在的角色，而適配器角色是需要新建立的，它的職責(zé)非常簡(jiǎn)單：把源角色轉(zhuǎn)換為目標(biāo)角色，怎么轉(zhuǎn)換？通過(guò)繼承或是類關(guān)聯(lián)的方式。

對(duì)象適配器

不使用多繼承或繼承的方式，而是使用直接關(guān)聯(lián)，或者稱為委托的方式。

對(duì)象適配器和類適配器的區(qū)別：

類適配器是類間繼承，對(duì)象適配器是對(duì)象的合成關(guān)系，也可以說(shuō)是類的關(guān)聯(lián)關(guān)系，這是兩者的根本區(qū)別。實(shí)際項(xiàng)目中對(duì)象適配器使用到的場(chǎng)景相對(duì)比較多。

代碼示例

public class Adapter extends Target
{
    private Adaptee adaptee;

    public Adapter(Adaptee adaptee)
    {
        this.adaptee=adaptee;
    }

    public void request()
    {
        adaptee.specificRequest();
    }
} 

迭代器模式

概念

它提供一種方法訪問(wèn)一個(gè)容器對(duì)象中各個(gè)元素，而又不需暴露該對(duì)象的內(nèi)部細(xì)節(jié)。

結(jié)構(gòu)

Iterator 抽象迭代器：抽象迭代器負(fù)責(zé)定義訪問(wèn)和遍歷元素的接口，而且基本上是有固定的 3 個(gè)方法：first()獲得第一個(gè)元素，next()訪問(wèn)下一個(gè)元素，isDone()是否已經(jīng)訪問(wèn)到底部（Java 叫做 hasNext()方法）。

ConcreteIterator 具體迭代器：具體迭代器角色要實(shí)現(xiàn)迭代器接口，完成容器元素的遍歷。

Aggregate 抽象容器：容器角色負(fù)責(zé)提供創(chuàng)建具體迭代器角色的接口，必然提供一個(gè)類似createIterator()這樣的方法，在 Java 中一般是 iterator()方法。

Concrete Aggregate 具體容器：具體容器實(shí)現(xiàn)容器接口定義的方法，創(chuàng)建出容納迭代器的對(duì)象。

代碼示例

/**
 * 具體迭代器
 */
public class ConcreteIterator<T> implements Iterator<T> {

    private List<T> list = new ArrayList<>();

    private int cursor = 0;

    public boolean hasNext() {
        return cursor != list.size();
    }

    public T next() {
        T obj = null;
        if (this.hasNext()) {
            obj = this.list.get(cursor++);
        }
        return obj;
    }

}

組合模式

概念

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

使用場(chǎng)景

• 維護(hù)和展示部分-整體關(guān)系的場(chǎng)景，如樹(shù)形菜單、文件和文件夾管理。

• 從一個(gè)整體中能夠獨(dú)立出部分模塊或功能的場(chǎng)景。

• 只要是樹(shù)形結(jié)構(gòu)，就考慮使用組合模式。

結(jié)構(gòu)

Component 抽象構(gòu)件角色：定義參加組合對(duì)象的共有方法和屬性，可以定義一些默認(rèn)的行為或?qū)傩浴?/p>

Leaf 葉子構(gòu)件：葉子對(duì)象，其下再也沒(méi)有其他的分支，也就是遍歷的最小單位。

Composite 樹(shù)枝構(gòu)件：樹(shù)枝對(duì)象，它的作用是組合樹(shù)枝節(jié)點(diǎn)和葉子節(jié)點(diǎn)形成一個(gè)樹(shù)形結(jié)構(gòu)。

代碼示例

public class Composite extends Component {
    //構(gòu)件容器
    private ArrayList<Component> componentArrayList = new
            ArrayList<Component>();
    //增加一個(gè)葉子構(gòu)件或樹(shù)枝構(gòu)件
    public void add(Component component){
        this.componentArrayList.add(component);
    }
    //刪除一個(gè)葉子構(gòu)件或樹(shù)枝構(gòu)件
    public void remove(Component component){
        this.componentArrayList.remove(component);
    }
    //獲得分支下的所有葉子構(gòu)件和樹(shù)枝構(gòu)件
    public ArrayList<Component> getChildren(){
        return this.componentArrayList;
    } 
}

觀察者模式

概念

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

使用場(chǎng)景

• 關(guān)聯(lián)行為場(chǎng)景。需要注意的是，關(guān)聯(lián)行為是可拆分的，而不是“組合”關(guān)系。

• 事件多級(jí)觸發(fā)場(chǎng)景。

• 跨系統(tǒng)的消息交換場(chǎng)景，如消息隊(duì)列的處理機(jī)制。

結(jié)構(gòu)

Subject 被觀察者：定義被觀察者必須實(shí)現(xiàn)的職責(zé)，它必須能夠動(dòng)態(tài)地增加、取消觀察者。它一般是抽象類或者是實(shí)現(xiàn)類，僅僅完成作為被觀察者必須實(shí)現(xiàn)的職責(zé)：管理觀察者并通知觀察者。

Observer 觀察者：觀察者接收到消息后，即進(jìn)行 update（更新方法）操作，對(duì)接收到的信息進(jìn)行處理。

ConcreteSubject 具體的被觀察者：定義被觀察者自己的業(yè)務(wù)邏輯，同時(shí)定義對(duì)哪些事件進(jìn)行通知。

ConcreteObserver 具體的觀察者：每個(gè)觀察在接收到消息后的處理反應(yīng)是不同，各個(gè)觀察者有自己的處理邏輯。

代碼示例

public abstract class Subject {
    //定義一個(gè)觀察者數(shù)組
    private Vector<Observer> obsVector = new Vector<Observer>();
    //增加一個(gè)觀察者
    public void addObserver(Observer o){
        this.obsVector.add(o);
    }
    //刪除一個(gè)觀察者
    public void delObserver(Observer o){
        this.obsVector.remove(o);
    }
    //通知所有觀察者
    public void notifyObservers(){
        for(Observer o:this.obsVector){
            o.update();
        }
    } 
}

門面模式

概念

要求一個(gè)子系統(tǒng)的外部與其內(nèi)部的通信必須通過(guò)一個(gè)統(tǒng)一的對(duì)象進(jìn)行。門面模式提供一個(gè)高層次的接口，使得子系統(tǒng)更易于使用。

使用場(chǎng)景

• 為一個(gè)復(fù)雜的模塊或子系統(tǒng)提供一個(gè)供外界訪問(wèn)的接口

• 子系統(tǒng)相對(duì)獨(dú)立——外界對(duì)子系統(tǒng)的訪問(wèn)只要黑箱操作即可

• 預(yù)防低水平人員帶來(lái)的風(fēng)險(xiǎn)擴(kuò)散

結(jié)構(gòu)

Facade 門面角色：客戶端可以調(diào)用這個(gè)角色的方法。此角色知曉子系統(tǒng)的所有功能和責(zé)任。一般情況下，本角色會(huì)將所有從客戶端發(fā)來(lái)的請(qǐng)求委派到相應(yīng)的子系統(tǒng)去，也就說(shuō)該角色沒(méi)有實(shí)際的業(yè)務(wù)邏輯，只是一個(gè)委托類。

subsystem 子系統(tǒng)角色：可以同時(shí)有一個(gè)或者多個(gè)子系統(tǒng)。每一個(gè)子系統(tǒng)都不是一個(gè)單獨(dú)的類，而是一個(gè)類的集合。子系統(tǒng)并不知道門面的存在。對(duì)于子系統(tǒng)而言，門面僅僅是另外一個(gè)客戶端而已。

代碼模式

public class Client {
    //委托的子系統(tǒng)對(duì)象
    private A a= new A();
    private B b= new B();
    private C c= new C();
    //提供外部訪問(wèn)的方法
    public void methodA(){
        this.a.doSomething();
    }
    public void methodB(){
        this.b.doSomething();
    }
    public void methodC(){
        this.c.doSomething();
    }
}

備忘錄模式

概念

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

使用場(chǎng)景

• 需要保存和恢復(fù)數(shù)據(jù)的相關(guān)狀態(tài)場(chǎng)景。

• 提供一個(gè)可回滾（rollback）的操作。

• 需要監(jiān)控的副本場(chǎng)景中。

• 數(shù)據(jù)庫(kù)連接的事務(wù)管理就是用的備忘錄模式。

結(jié)構(gòu)

Originator 發(fā)起人角色：記錄當(dāng)前時(shí)刻的內(nèi)部狀態(tài)，負(fù)責(zé)定義哪些屬于備份范圍的狀態(tài)，負(fù)責(zé)創(chuàng)建和恢復(fù)備忘錄數(shù)據(jù)。

Memento 備忘錄角色：負(fù)責(zé)存儲(chǔ) Originator 發(fā)起人對(duì)象的內(nèi)部狀態(tài)，在需要的時(shí)候提供發(fā)起人需要的內(nèi)部狀態(tài)。

Caretaker 備忘錄管理員角色：對(duì)備忘錄進(jìn)行管理、保存和提供備忘錄。

代碼示例

public class BeanUtils {
    //把 bean 的所有屬性及數(shù)值放入到 Hashmap 中
    public static HashMap<String,Object> backupProp(Object bean){
        HashMap<String,Object> result = new
                HashMap<String,Object>();
        try {
            //獲得 Bean 描述
            BeanInfo
                    beanInfo=Introspector.getBeanInfo(bean.getClass());
            //獲得屬性描述
            PropertyDescriptor[]
                    descriptors=beanInfo.getPropertyDescriptors();
            //遍歷所有屬性
            for(PropertyDescriptor des:descriptors){
                //屬性名稱
                String fieldName = des.getName();
                //讀取屬性的方法
                Method getter = des.getReadMethod();
                //讀取屬性值
                Object fieldValue=getter.invoke(bean,new
                        Object[]{});
                if(!fieldName.equalsIgnoreCase("class")){
                    result.put(fieldName, fieldValue);
                } } } catch (Exception e) {
                //異常處理
        }
        return result;
    }
    //把 HashMap 的值返回到 bean 中
    public static void restoreProp(Object bean,HashMap<String,Object>
            propMap){
        try {
            //獲得 Bean 描述
            BeanInfo beanInfo =
                    Introspector.getBeanInfo(bean.getClass());
            //獲得屬性描述
            PropertyDescriptor[] descriptors =
                    beanInfo.getPropertyDescriptors();
            //遍歷所有屬性
            for(PropertyDescriptor des:descriptors){
                //屬性名稱
                String fieldName = des.getName();
                //如果有這個(gè)屬性
                if(propMap.containsKey(fieldName)){
                    //寫屬性的方法
                    Method setter = des.getWriteMethod();
                    setter.invoke(bean, new
                            Object[]{propMap.get(fieldName)});
                } } } catch (Exception e) {
            //異常處理
            System.out.println("shit");
            e.printStackTrace();
        }
    }
}

訪問(wèn)者模式

概念

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

使用場(chǎng)景

• 一個(gè)對(duì)象結(jié)構(gòu)包含很多類對(duì)象，它們有不同的接口，而你想對(duì)這些對(duì)象實(shí)施一些依賴于其具體類的操作，也就說(shuō)是用迭代器模式已經(jīng)不能勝任的情景。

• 需要對(duì)一個(gè)對(duì)象結(jié)構(gòu)中的對(duì)象進(jìn)行很多不同并且不相關(guān)的操作，而你想避免讓這些操作“污染”這些對(duì)象的類。

結(jié)構(gòu)

Visitor——抽象訪問(wèn)者：抽象類或者接口，聲明訪問(wèn)者可以訪問(wèn)哪些元素，具體到程序中就是 visit 方法的參數(shù)定義哪些對(duì)象是可以被訪問(wèn)的。

ConcreteVisitor——具體訪問(wèn)者：它影響訪問(wèn)者訪問(wèn)到一個(gè)類后該怎么干，要做什么事情。

Element——抽象元素：接口或者抽象類，聲明接受哪一類訪問(wèn)者訪問(wèn)，程序上是通過(guò) accept 方法中的參數(shù)來(lái)定義的。

ConcreteElement——具體元素：實(shí)現(xiàn) accept 方法，通常是 visitor.visit(this)，基本上都形成了一種模式了。

ObjectStruture——結(jié)構(gòu)對(duì)象：元素產(chǎn)生者，一般容納在多個(gè)不同類、不同接口的容器，如 List、Set、Map 等，在項(xiàng)目中，一般很少抽象出這個(gè)角色。

代碼示例

public class CompensationVisitor implements Visitor {

    @Override
    public void Visit(Element element) {
        // TODO Auto-generated method stub
        Employee employee = ((Employee) element);

        System.out.println(
                employee.getName() + "'s Compensation is " + (employee.getDegree() * employee.getVacationDays() * 10));
    }

}

狀態(tài)模式

概念

當(dāng)一個(gè)對(duì)象內(nèi)在狀態(tài)改變時(shí)允許其改變行為，這個(gè)對(duì)象看起來(lái)像改變了其類。

使用場(chǎng)景

• 行為隨狀態(tài)改變而改變的場(chǎng)景，這也是狀態(tài)模式的根本出發(fā)點(diǎn)，例如權(quán)限設(shè)計(jì)，人員的狀態(tài)不同即使執(zhí)行相同的行為結(jié)果也會(huì)不同，在這種情況下需要考慮使用狀態(tài)模式。

• 條件、分支判斷語(yǔ)句的替代者

結(jié)構(gòu)

State——抽象狀態(tài)角色：接口或抽象類，負(fù)責(zé)對(duì)象狀態(tài)定義，并且封裝環(huán)境角色以實(shí)現(xiàn)狀態(tài)切換。

ConcreteState——具體狀態(tài)角色：每一個(gè)具體狀態(tài)必須完成兩個(gè)職責(zé)：本狀態(tài)的行為管理以及趨向狀態(tài)處理，通俗地說(shuō)，就是本狀態(tài)下要做的事情，以及本狀態(tài)如何過(guò)渡到其他狀態(tài)。

Context——環(huán)境角色：定義客戶端需要的接口，并且負(fù)責(zé)具體狀態(tài)的切換。

代碼示例

//抽象狀態(tài)角色
public abstract class State {
     //定義一個(gè)環(huán)境角色，提供子類訪問(wèn)
     protected Context context;
     //設(shè)置環(huán)境角色
     public void setContext(Context _context){
             this.context = _context;
     }
     //行為1
     public abstract void handle1();
     //行為2
     public abstract void handle2();
}

解釋器模式

概念

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

使用場(chǎng)景

• 重復(fù)發(fā)生的問(wèn)題可以使用解釋器模式

• 一個(gè)簡(jiǎn)單語(yǔ)法需要解釋的場(chǎng)景

結(jié)構(gòu)

AbstractExpression——抽象解釋器：具體的解釋任務(wù)由各個(gè)實(shí)現(xiàn)類完成，具體的解釋器分別由TerminalExpression 和 Non-terminalExpression 完成。

TerminalExpression——終結(jié)符表達(dá)式：實(shí)現(xiàn)與文法中的元素相關(guān)聯(lián)的解釋操作，通常一個(gè)解釋器模式中只有一個(gè)終結(jié)符表達(dá)式，但有多個(gè)實(shí)例，對(duì)應(yīng)不同的終結(jié)符。

NonterminalExpression——非終結(jié)符表達(dá)式：文法中的每條規(guī)則對(duì)應(yīng)于一個(gè)非終結(jié)表達(dá)式，非終結(jié)符表達(dá)式根據(jù)邏輯的復(fù)雜程度而增加，原則上每個(gè)文法規(guī)則都對(duì)應(yīng)一個(gè)非終結(jié)符表達(dá)式。

Context——環(huán)境角色：一般是用來(lái)存放文法中各個(gè)終結(jié)符所對(duì)應(yīng)的具體值，這些信息需要存放到環(huán)境角色中，很多情況下我們使用 Map 來(lái)充當(dāng)環(huán)境角色就足夠了。

代碼示例

/**
 * 終結(jié)符表達(dá)式
 */
public class TerminalExpression extends AbstractExpression {

    @Override
    public void interpret(Context ctx) {
        // 實(shí)現(xiàn)與語(yǔ)法規(guī)則中的終結(jié)符相關(guān)聯(lián)的解釋操作

    }

}

/**
 * 非終結(jié)符表達(dá)式
 */
public class NonterminalExpression extends AbstractExpression {

    @Override
    public void interpret(Context ctx) {
        // 實(shí)現(xiàn)與語(yǔ)法規(guī)則中的非終結(jié)符相關(guān)聯(lián)的解釋操作

    }

}

享元模式

概念

使用共享對(duì)象可有效地支持大量的細(xì)粒度的對(duì)象。

對(duì)象的信息分為兩個(gè)部分：內(nèi)部狀態(tài)（intrinsic）與外部狀態(tài)（extrinsic）。

內(nèi)部狀態(tài)：內(nèi)部狀態(tài)是對(duì)象可共享出來(lái)的信息，存儲(chǔ)在享元對(duì)象內(nèi)部并且不會(huì)隨環(huán)境改變而改變。

外部狀態(tài)：外部狀態(tài)是對(duì)象得以依賴的一個(gè)標(biāo)記，是隨環(huán)境改變而改變的、不可以共享的狀態(tài)。

使用場(chǎng)景

• 系統(tǒng)中存在大量的相似對(duì)象。

• 細(xì)粒度的對(duì)象都具備較接近的外部狀態(tài)，而且內(nèi)部狀態(tài)與環(huán)境無(wú)關(guān)，也就是說(shuō)對(duì)象沒(méi)有特定身份。

• 需要緩沖池的場(chǎng)景。

結(jié)構(gòu)

Flyweight——抽象享元角色：它簡(jiǎn)單地說(shuō)就是一個(gè)產(chǎn)品的抽象類，同時(shí)定義出對(duì)象的外部狀態(tài)和內(nèi)部狀態(tài)的接口或?qū)崿F(xiàn)。

ConcreteFlyweight——具體享元角色：具體的一個(gè)產(chǎn)品類，實(shí)現(xiàn)抽象角色定義的業(yè)務(wù)。該角色中需要注意的是內(nèi)部狀態(tài)處理應(yīng)該與環(huán)境無(wú)關(guān)，不應(yīng)該出現(xiàn)一個(gè)操作改變了內(nèi)部狀態(tài)，同時(shí)修改了外部狀態(tài)，這是絕對(duì)不允許的。

unsharedConcreteFlyweight——不可共享的享元角色：不存在外部狀態(tài)或者安全要求（如線程安全）不能夠使用共享技術(shù)的對(duì)象，該對(duì)象一般不會(huì)出現(xiàn)在享元工廠中。

FlyweightFactory——享元工廠：職責(zé)非常簡(jiǎn)單，就是構(gòu)造一個(gè)池容器，同時(shí)提供從池中獲得對(duì)象的方法。

代碼示例

public class FlyweightFactory {
    //定義一個(gè)池容器
    private static HashMap<String,Flyweight> pool= new
            HashMap<String,Flyweight>();
    //享元工廠
    public static Flyweight getFlyweight(String Extrinsic){
        //需要返回的對(duì)象
        Flyweight flyweight = null;
        //在池中沒(méi)有該對(duì)象
        if(pool.containsKey(Extrinsic)){
            flyweight = pool.get(Extrinsic);
        }else{
            //根據(jù)外部狀態(tài)創(chuàng)建享元對(duì)象
            flyweight = new ConcreteFlyweight1(Extrinsic);
            //放置到池中
            pool.put(Extrinsic, flyweight);
        }
        return flyweight;
    }
}

橋梁模式

概念

將抽象和實(shí)現(xiàn)解耦，使得兩者可以獨(dú)立地變化。

使用場(chǎng)景

• 不希望或不適用使用繼承的場(chǎng)景

• 接口或抽象類不穩(wěn)定的場(chǎng)景

• 重用性要求較高的場(chǎng)景

結(jié)構(gòu)

Abstraction——抽象化角色：它的主要職責(zé)是定義出該角色的行為，同時(shí)保存一個(gè)對(duì)實(shí)現(xiàn)化角色的引用，該角色一般是抽象類。

Implementor——實(shí)現(xiàn)化角色：它是接口或者抽象類，定義角色必需的行為和屬性。

RefinedAbstraction——修正抽象化角色：它引用實(shí)現(xiàn)化角色對(duì)抽象化角色進(jìn)行修正。

ConcreteImplementor——具體實(shí)現(xiàn)化角色：它實(shí)現(xiàn)接口或抽象類定義的方法和屬性。

代碼示例

public abstract class Abstraction {
    //定義對(duì)實(shí)現(xiàn)化角色的引用
    private Implementor imp;
    //約束子類必須實(shí)現(xiàn)該構(gòu)造函數(shù)
    public Abstraction(Implementor _imp){
        this.imp = _imp;
    }
    //自身的行為和屬性
    public void request(){
        this.imp.doSomething();
    }
    //獲得實(shí)現(xiàn)化角色
    public Implementor getImp(){
        return imp;
    }
}

總結(jié)

大家在學(xué)習(xí)設(shè)計(jì)模式的時(shí)候，不要把它看得有多難，歸根結(jié)底，都是一些概論性的總結(jié)。需要我們?cè)谄綍r(shí)的不斷學(xué)習(xí)和工作中，慢慢去理解它的深層原理，這樣才能靈活應(yīng)用每一種設(shè)計(jì)模式。

設(shè)計(jì)模式是在前人的總結(jié)上，對(duì)一些場(chǎng)景的問(wèn)題的進(jìn)行解決的一種方案，設(shè)計(jì)模式不是公式，沒(méi)必要去死記硬背每一種模式，更重要的是了解它的抽象思想，以及應(yīng)用設(shè)計(jì)模式怎么更好的解決問(wèn)題，可以達(dá)成什么效果。理論雖多，但是我們要把它掌握的話，對(duì)于我們的實(shí)際開(kāi)發(fā)來(lái)說(shuō)會(huì)解決不少的問(wèn)題。

當(dāng)然后面還會(huì)繼續(xù)為大家更新關(guān)于設(shè)計(jì)原則的內(nèi)容，方便大家進(jìn)一步理解設(shè)計(jì)模式。