本笔记摘抄自：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里面的实现还没有研究透，如果以后有了新的学习内容，再补充进来。但是我感觉，这个模式可能在业务系统里面有更大的使用。
五、总结
此处略去若干字。