本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/8032683.html,記錄一下學習過程以備後續查用。 一、引言 今天我們要講行為型設計模式的第六個模式--狀態模式。無論是現實世界,還是面向對象的OO世界,裡面都有一個東西,那就是對象。有對象當然就有 狀態了 ...
本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/8032683.html,記錄一下學習過程以備後續查用。
一、引言
今天我們要講行為型設計模式的第六個模式--狀態模式。無論是現實世界,還是面向對象的OO世界,裡面都有一個東西,那就是對象。有對象當然就有
狀態了。每個對象都有其對應的狀態,而每個狀態又有對應一些相應的行為。在不同狀態下,行為的的方式也是不一樣。如果某個對象有多個狀態時,那
麽就會有很多對應的行為。對這些狀態的判斷以及依狀態完成的行為,會導致多重條件語句交織在一起。另外,如果添加一種新的狀態時,需要更改之前
現有的代碼。這樣的設計顯然違背了開閉原則,狀態模式正是用來解決這樣的問題的。
二、狀態模式介紹
狀態模式:英文名稱--State Pattern;分類--行為型。
2.1、動機(Motivate)
在軟體構建過程中,某些對象的狀態如果改變,其行為也會隨之發生變化。比如文檔處於只讀狀態,其支持的行為與讀寫狀態時支持的行為就可能完全
不同。如何在運行時根據對象的狀態來透明地更改對象的行為,而不會為對象操作和狀態轉化之間引入緊耦合?
2.2、意圖(Intent)
允許一個對象在其內部狀態改變時改變它的行為,從而使對象看起來似乎修改了其行為。——《設計模式》GoF
2.3、結構圖(Structure)
2.4、模式的組成
可以看出,在狀態模式的結構圖有以下角色:
1)環境角色(Context):也稱上下文,定義客戶端所感興趣的介面,並且保留一個具體狀態類的實例,這個實例給出此環境對象的現有狀態。
2)抽象狀態角色(State):定義一個介面,用以封裝環境對象的一個特定的狀態所對應的行為。
3)具體狀態角色(ConcreteState):每一個具體狀態類都實現了環境(Context)的一個狀態所對應的行為。
在狀態模式結構中需要理解環境類與抽象狀態類的作用:
環境類實際上就是擁有狀態的對象,環境類有時候可以充當狀態管理器(State Manager)的角色,可以在環境類中對狀態進行切換操作。
抽象狀態類可以是抽象類,也可以是介面。不同狀態類就是繼承這個父類的不同子類,狀態類的產生是由於環境類存在多個狀態,同時還滿足兩個條件:
這些狀態經常需要切換,在不同的狀態下對象的行為不同,因此可以將不同狀態下對象的行為單獨提取出來封裝在具體的狀態類中,使得環境類對象在其
內部狀態改變時可以改變它的行為。對象看起來似乎修改了它的類,而實際上是由於切換到不同的具體狀態類實現的;由於環境類可以設置為任一具體狀
態類,因此它針對抽象狀態類進行編程,在程式運行時可以將任一具體狀態類的對象設置到環境類中,從而使得環境類可以改變內部狀態,並且改變行為。
2.5、狀態模式的具體實現
狀態模式在我們的現實生活中也有類似的例子,例如:在我們網購的過程中,可以隨時查看訂單的具體狀態。對於商家來說,依訂單的不同狀態,會允
許客戶有不同的動作要求:比如:訂單在已發貨狀態時是不允許退貨的;如果訂單在備貨階段,客戶是可以退換貨的;客戶在收到貨物時,如果存在質量
問題可以拒簽,此時商家也可以變通打折促使客戶讓步接收。今天我們就以訂單為例來說明狀態模式的實現,實現代碼如下:
class Program { /// <summary> /// 環境角色--相當於Context類型 /// </summary> public sealed class Order { private IState current; public double Minute { get; set; } public bool IsCancel { get; set; } public bool TaskFinished { get; set; } public Order() { //工作狀態初始化為尚無的工作狀態,等待接單中。 current = new WaitForAcceptance(); IsCancel = false; } public void SetState(IState state) { current = state; } public void Action() { current.Process(this); } } /// <summary> /// 抽象狀態角色--相當於State類型 /// </summary> public interface IState { //處理訂單 void Process(Order order); } /// <summary> /// 等待受理--相當於具體狀態角色 /// </summary> public sealed class WaitForAcceptance : IState { public void Process(Order order) { Console.WriteLine("開始受理訂單,準備備貨。"); if (order.Minute < 30 && order.IsCancel) { Console.WriteLine("半個小時之內的訂單,客戶可以自行取消。"); order.SetState(new CancelOrder()); order.Action(); } else { order.SetState(new AcceptAndDeliver()); order.TaskFinished = false; order.Action(); } } } /// <summary> /// 受理髮貨--相當於具體狀態角色 /// </summary> public sealed class AcceptAndDeliver : IState { public void Process(Order order) { Console.WriteLine("貨物已經準備好,可以發貨了,不可以撤銷訂單。"); if (order.Minute < 30 && order.IsCancel) { Console.WriteLine("接受半個小時之內取消的訂單。"); order.SetState(new CancelOrder()); order.Action(); } if (order.TaskFinished == false) { order.SetState(new ConfirmationReceipt()); order.Action(); } } } /// <summary> /// 確認收貨--相當於具體狀態角色 /// </summary> public sealed class ConfirmationReceipt : IState { public void Process(Order order) { Console.WriteLine("客戶已簽收。"); order.SetState(new Success()); order.Action(); } } /// <summary> /// 交易成功--相當於具體狀態角色 /// </summary> public sealed class Success : IState { public void Process(Order order) { Console.WriteLine("訂單已結算。"); order.TaskFinished = true; } } /// <summary> /// 取消訂單--相當於具體狀態角色 /// </summary> public sealed class CancelOrder : IState { public void Process(Order order) { Console.WriteLine("訂單已取消。"); order.TaskFinished = true; } } static void Main(string[] args) { #region 狀態模式 //新接收訂單1 Order order1 = new Order { Minute = 9 }; order1.Action(); Console.WriteLine(); //新接收訂單2 Order order2 = new Order { Minute = 20 }; order2.IsCancel = true; order2.Action(); Console.WriteLine(); //新接收訂單3 Order order3 = new Order { Minute = 33 }; order3.IsCancel = true; order3.Action(); Console.Read(); #endregion } }View Code
運行結果如下:
三、狀態模式的實現要點
State模式將所有與一個特定狀態相關的行為都放入一個State的子類對象中。在對象狀態切換時,切換相應的對象,但同時維持State的介面,這樣實現
了具體操作與狀態轉換之間的解耦。為不同的狀態引入不同的對象使得狀態轉換變得更加明確,而且可以保證不會出現狀態不一致的情況,因為轉換是原
子性的--即要麼徹底轉換過來,要麼不轉換。
如果State對象沒有實例變數,那麼各個上下文可以共用同一個State對象,從而節省對象開銷。
3.1、狀態模式的優點
1)封裝了轉換規則。
2)枚舉可能的狀態,在枚舉狀態之前需要確定狀態種類。
3)將所有與某個狀態有關的行為放到一個類中,並且可以方便地增加新的狀態,只需要改變對象狀態即可改變對象的行為。
4)允許狀態轉換邏輯與狀態對象合成一體,而不是某一個巨大的條件語句塊。
5)可以讓多個環境對象共用一個狀態對象,從而減少系統中對象的個數。
3.2、狀態模式的缺點
1)狀態模式的使用必然會增加系統類和對象的個數。
2)狀態模式的結構與實現都較為複雜,如果使用不當將導致程式結構和代碼的混亂。
3)狀態模式對“開閉原則”的支持並不太好,對於可以切換狀態的狀態模式,增加新的狀態類需要修改那些負責狀態轉換的源代碼,否則無法切換到新增
狀態,另外修改某個狀態類的行為也需修改對應類的源代碼。
3.3、在以下情況下可以使用狀態模式
1)對象的行為依賴於它的狀態(屬性)並且可以根據它的狀態改變而改變它的相關行為。
2)代碼中包含大量與對象狀態有關的條件語句,這些條件語句的出現,會導致代碼的可維護性和靈活性變差,不能方便地增加和刪除狀態,使客戶類與
類庫之間的耦合增強。在這些條件語句中包含了對象的行為,而且這些條件對應於對象的各種狀態。
四、.NET中狀態模式的實現
狀態模式在.Net裡面的實現還沒有研究透,如果以後有了新的學習內容,再補充進來。但是我感覺,這個模式可能在業務系統裡面有更大的使用。
五、總結
此處略去若幹字。