Java設計模式之狀態(tài)模式
實際開發(fā)中訂單往往都包含著訂單狀態(tài),用戶每進行一次操作都要切換對應的狀態(tài),而每次切換判斷當前的狀態(tài)是必須的,就不可避免的引入一系列判斷語句,為了讓代碼更加清晰直觀,我們引入今天的主角——狀態(tài)模式。
一、概念理解
假設訂單狀態(tài)有,下單、發(fā)貨、確認收貨,如果用戶確認收貨,在常規(guī)編程中就要判斷當前用戶的狀態(tài),然后再修改狀態(tài),如果這種情況下使用狀態(tài)模式。
將各個狀態(tài)都抽象成一個狀態(tài)類,比如下單狀態(tài)類、發(fā)貨狀態(tài)類、確認收貨類,在狀態(tài)類中處理相應的邏輯和控制下一個狀態(tài),在定義一個環(huán)境類,定義初始狀態(tài),并控制切換狀態(tài)。
在狀態(tài)模式中應該包含著三個角色:
環(huán)境類(Context)角色:也稱為上下文,它定義了客戶端需要的接口,內部維護一個當前狀態(tài),這個類持有State接口,負責保持并切換當前的狀態(tài)。
抽象狀態(tài)(State)角色:定義一個接口,用以封裝環(huán)境對象中的特定狀態(tài)所對應的行為,可以有一個或多個行為。
具體狀態(tài)(Concrete State)角色:實現抽象狀態(tài)所對應的行為,并且在需要的情況下進行狀態(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)案例實現demo。
二、案例實現
抽象狀態(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)-訂單付款:
實現狀態(tài)接口,處理相應的邏輯,并定義下一個狀態(tài)
/** * 訂單付款 * @author tcy * @Date 21-09-2022 */ public class OrderStatePay extends OrderStateAbstract { @Override public void handle() { System.out.println("訂單已支付,執(zhí)行下個狀態(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("訂單已經發(fā)貨,開始下一狀態(tài)..."); context.changeState(new OrderStateSubmit()); } }
具體狀態(tài)-訂單確認收貨
/** * 訂單提交 * @author tcy * @Date 21-09-2022 */ public class OrderStateSubmit extends OrderStateAbstract { @Override public void handle() { System.out.println("訂單已經確認收貨..."); } }
環(huán)境類:
持有最新狀態(tài),并調用具體的狀態(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); } /** * 審批通過請求 */ public void request() { this.state.handle(); } }
客戶端調用:
/** * @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)模式客戶端調用比較簡單,由狀態(tài)內部類進行狀態(tài)切換。
三、總結
很多博客都將策略模式的案例代碼當做狀態(tài)模式來講解,這是不正確的,讀者可以參考策略模式兩篇做對比學習,認真體會他們之間的區(qū)別。
在實際開發(fā)中,當控制一個對象狀態(tài)轉換的條件表達式過于復雜時,就可以使用狀態(tài)模式把相關“判斷邏輯”提取出來,用各個不同的類進行表示。
系統(tǒng)處于哪種情況,直接使用相應的狀態(tài)類對象進行處理,這樣能把原來復雜的邏輯判斷簡單化,消除了 if-else、switch-case 等冗余語句,代碼更有層次性,并且具備良好的擴展力。
比如審批流程,我們案例也僅僅是用于訂單流程做例子,在實際開發(fā)中并不會使用這種方式處理訂單,因為訂單的處理邏輯實際上并不是那么復雜,引入狀態(tài)模式反而增加了更多的類,造成系統(tǒng)更加的復雜,這也是設計模式最顯著的缺點。
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
相關文章
SpringBoot使用FreeMarker模板發(fā)送郵件
這篇文章主要為大家詳細介紹了SpringBoot使用FreeMarker模板發(fā)送郵件,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2019-04-04在Ubuntu系統(tǒng)下安裝JDK和Tomcat的教程
這篇文章主要介紹了在Ubuntu系統(tǒng)下安裝JDK和Tomcat的教程,這樣便是在Linux系統(tǒng)下搭建完整的Java和JSP開發(fā)環(huán)境,需要的朋友可以參考下2015-08-08