實(shí)際開發(fā)中訂單往往都包含著訂單狀態(tài)，用戶每進(jìn)行一次操作都要切換對(duì)應(yīng)的狀態(tài)，而每次切換判斷當(dāng)前的狀態(tài)是必須的，就不可避免的引入一系列判斷語句，為了讓代碼更加清晰直觀，我們引入今天的主角——狀態(tài)模式。

一、概念理解

假設(shè)訂單狀態(tài)有，下單、發(fā)貨、確認(rèn)收貨，如果用戶確認(rèn)收貨，在常規(guī)編程中就要判斷當(dāng)前用戶的狀態(tài)，然后再修改狀態(tài)，如果這種情況下使用狀態(tài)模式。

將各個(gè)狀態(tài)都抽象成一個(gè)狀態(tài)類，比如下單狀態(tài)類、發(fā)貨狀態(tài)類、確認(rèn)收貨類，在狀態(tài)類中處理相應(yīng)的邏輯和控制下一個(gè)狀態(tài)，在定義一個(gè)環(huán)境類，定義初始狀態(tài)，并控制切換狀態(tài)。

在狀態(tài)模式中應(yīng)該包含著三個(gè)角色：

環(huán)境類（Context）角色：也稱為上下文，它定義了客戶端需要的接口，內(nèi)部維護(hù)一個(gè)當(dāng)前狀態(tài)，這個(gè)類持有State接口，負(fù)責(zé)保持并切換當(dāng)前的狀態(tài)。

抽象狀態(tài)（State）角色：定義一個(gè)接口，用以封裝環(huán)境對(duì)象中的特定狀態(tài)所對(duì)應(yīng)的行為，可以有一個(gè)或多個(gè)行為。

具體狀態(tài)（Concrete State）角色：實(shí)現(xiàn)抽象狀態(tài)所對(duì)應(yīng)的行為，并且在需要的情況下進(jìn)行狀態(tài)切換。

以下為狀態(tài)模式的類圖，看起來是很直觀的，理解起來也簡單，我們需要說明的是狀態(tài)模式的類圖和策略模式的類圖長的一樣，但寫起來狀態(tài)模式比策略模式要難。

我們要注意這段話，在狀態(tài)模式中，類的行為是基于它的狀態(tài)改變的，狀態(tài)之間的切換，在狀態(tài)A執(zhí)行完畢后自己控制狀態(tài)指向狀態(tài)B，狀態(tài)模式是不停的切換狀態(tài)執(zhí)行。這也是狀態(tài)模式和策略模式不一樣的地方。

另外在狀態(tài)模式中，狀態(tài)A到B是由自己控制的，而不是由客戶端來控制，這是狀態(tài)模式和策略模式最顯著的特征。

我們基于訂單狀態(tài)案例實(shí)現(xiàn)demo。

二、案例實(shí)現(xiàn)

抽象狀態(tài)：

定義統(tǒng)一的狀態(tài)切換方法

/**
 * 抽象狀態(tài)
 * @author tcy
 * @Date 20-09-2022
 */
public abstract class OrderStateAbstract {
    protected Context context;

    public void setContext(Context context) {
        this.context = context;
    }
        /**
         * 狀態(tài)切換
         */
    public abstract void handle();

}

具體狀態(tài)-訂單付款：

實(shí)現(xiàn)狀態(tài)接口，處理相應(yīng)的邏輯，并定義下一個(gè)狀態(tài)

/**
 * 訂單付款
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStatePay extends OrderStateAbstract {
   @Override
    public void handle() {
        System.out.println("訂單已支付,執(zhí)行下個(gè)狀態(tài)...");
        context.changeState(new OrderStateOut());

    }
}

具體狀態(tài)-訂單發(fā)貨

/**
 * 訂單發(fā)貨
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStateOut extends OrderStateAbstract {
     @Override
    public void handle() {
        System.out.println("訂單已經(jīng)發(fā)貨，開始下一狀態(tài)...");
        context.changeState(new OrderStateSubmit());
    }
}

具體狀態(tài)-訂單確認(rèn)收貨

/**
 * 訂單提交
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStateSubmit extends OrderStateAbstract {
    @Override
    public void handle() {
        System.out.println("訂單已經(jīng)確認(rèn)收貨...");
    }
}

環(huán)境類：

持有最新狀態(tài)，并調(diào)用具體的狀態(tài)切換方法

/**
 * 環(huán)境類
 * @author tcy
 * @Date 20-09-2022
 */
public class Context {

   private OrderStateAbstract state;

    //定義環(huán)境類的初始狀態(tài)
    public Context() {
        this.state = new OrderStatePay();
        state.setContext(this);
    }

	//狀態(tài)切換
    public void changeState(OrderStateAbstract state) {
        this.state = state;
        this.state.setContext(this);
    }


    /**
     * 審批通過請(qǐng)求
     */
    public void request() {
        this.state.handle();
    }
}

客戶端調(diào)用：

/**
 * @author tcy
 * @Date 20-09-2022
 */
public class Client {
    public static void main(String[] args) {

         //創(chuàng)建環(huán)境
        Context context = new Context();
        //訂單付款
        context.request();
        //訂單發(fā)貨
        context.request();
        //訂單付款
        context.request();

    }
}

狀態(tài)模式客戶端調(diào)用比較簡單，由狀態(tài)內(nèi)部類進(jìn)行狀態(tài)切換。

三、總結(jié)

很多博客都將策略模式的案例代碼當(dāng)做狀態(tài)模式來講解，這是不正確的，讀者可以參考策略模式兩篇做對(duì)比學(xué)習(xí)，認(rèn)真體會(huì)他們之間的區(qū)別。

在實(shí)際開發(fā)中，當(dāng)控制一個(gè)對(duì)象狀態(tài)轉(zhuǎn)換的條件表達(dá)式過于復(fù)雜時(shí)，就可以使用狀態(tài)模式把相關(guān)“判斷邏輯”提取出來，用各個(gè)不同的類進(jìn)行表示。

系統(tǒng)處于哪種情況，直接使用相應(yīng)的狀態(tài)類對(duì)象進(jìn)行處理，這樣能把原來復(fù)雜的邏輯判斷簡單化，消除了 if-else、switch-case 等冗余語句，代碼更有層次性，并且具備良好的擴(kuò)展力。

比如審批流程，我們案例也僅僅是用于訂單流程做例子，在實(shí)際開發(fā)中并不會(huì)使用這種方式處理訂單，因?yàn)橛唵蔚奶幚磉壿媽?shí)際上并不是那么復(fù)雜，引入狀態(tài)模式反而增加了更多的類，造成系統(tǒng)更加的復(fù)雜，這也是設(shè)計(jì)模式最顯著的缺點(diǎn)。

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

最新評(píng)論