本筆記摘抄自: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里面的實作還沒有研究透,如果以后有了新的學習內容,再補充進來,但是我感覺,這個模式可能在業務系統里面有更大的使用,
五、總結
此處略去若干字,
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/71345.html
標籤:C#
下一篇:C# 類的建構式 決議
