C#設計模式學習筆記:(18)狀態模式
本筆記摘抄自: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
}
}
執行結果如下:
三、狀態模式的實現要點
State模式將所有與一個特定狀態相關的行為都放入一個State的子類物件中。在物件狀態切換時,切換相應的物件,但同時維持State的介面,這樣實現
了具體操作與狀態轉換之間的解耦。為不同python基礎教程
的狀態引入不同的物件使得狀態轉換變得更加c#教程明確,而且可以保證不會出現狀態不一致的情況,因為轉換是原
子性的–即要麼徹底轉換過來,要麼不轉換。
如果State物件沒有例項變數,那麼各個上下文可以共享同一個State物件,從而節省物件開銷。
3.1、狀態模式的優點
1)封裝了轉換規則。
2)列舉可能的狀態,在列舉狀態之前需要確定狀態種類。
3)將所有與某個狀態有關的行為放到一個類中,並且可以方便地增加新的狀態,只需要改變物件狀態即可改變物件的行為。
4)允許狀態轉換邏輯與狀態物件合成一體,而不是某一個巨大的條件語句塊。
5)可以讓多個環境物件共享一個狀態物件,從而減少系統中物件的個數。
3.2、狀態模式的缺點
1)狀態模式的使用必然會增加系統類和物件的個數。
2)狀態模式的結構與實現都較為複雜,如果使用不當將導致程式結構和程式碼的混亂。
3)狀態模式對“開閉原則”的支援並不太好,對於可以切換狀態的狀態模式,增加新的狀態類需要修改那些負責狀態轉換的原始碼,否則無法切換到新增
狀態,另外修改某個狀態類的行為也需修改對應類的原始碼。
3.3、在以下情況下可以使用狀態模式
1)物件的行為依賴於它的狀態(屬性)並且可以根據它的狀態改變而改變它的相關行為。
2)程式碼中包含大量與物件狀態有關的條件語句,這些條件語句的出現,會導致程式碼的可維護性和靈活性變差,不能方便地增加和刪除狀態,使客戶類與
類庫之間的耦合增強。在這些條件語句中包含了物件的行為,而且這些條件對應於物件的各種狀態。
四、.NET中狀態模式的實現
狀態模式在.Net裡面的實現還沒有研究透,如果以後有了新的學習內容,再補充進來。但是我感覺,這個模式可能在業務系統裡面有更大的使用。
五、總結
此處略去若干字。