状态模式，从字面意思上来讲应该是很简单的，就是针对实际业务上的内容，当类的内部的状态发生改变时，给出不同的响应体，就像现实中的人一样，早上没有吃饭，状态不好，上班、上课都会打哈欠，中午了，吃过午饭，又吃太饱了，又有点困意了，到了晚上了，终于下班了，可以好好放松一下了，出去好好耍一耍，针对不同的时间有不同的状态，那么怎么在程序中实现呢，让其在不同的状态下给出不同的响应，使其状态发生改变后行为也发生改变。

　　这里我们就可以使用状态模式来实现这种实际存在的问题。

　　当一个类的状态发生改变时，伴随着类的行为发生了改变，这样就看起来是类发生了改变，这样的使用就是状态模式，那状态模式使用的场景又是什么呢？一般用于当控制一个对象状态转换的条件表达式过于复杂时的情况，把状态的判断逻辑转移到表示不同的一系列类当中，可以把负责的逻辑判断简单化。

　　模式中使用到的角色主要包含了上下文环境（它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理）、抽象状态（定义一个接口以封装使用上下文环境的的一个特定状态相关的行为）、具体状态（实现抽象状态定义的接口）。

　　下面我们简单地看一下其的UML图：

　　

　　具体的代码实现如下：

　　1、抽象状态类：

namespace StateDemo{    public abstract class State    {        public abstract void Handle(Context context);    }}

　　2、具体状态类：

namespace StateDemo{    public class ConcreteStateA:State    {        public override void Handle(Context context)        {            Console.WriteLine("当前状态为A，触发与A相关的场景");            context.State = new ConcreteStateB();        }    }}

namespace StateDemo{    public class ConcreteStateB:State    {        public override void Handle(Context context)        {            Console.WriteLine("当前状态为B，触发与B相关的场景");            context.State = new ConcreteStateA();        }    }}

　　3、上下文环境：

namespace StateDemo{    public class Context    {        private State _state { set; get; }        public State State        {            set { this._state = value; }            get { return this._state; }        }        public Context(State state)        {            this._state = state;        }        public void Request()        {            this._state.Handle(this);        }    }}

　　4、Main方法：

namespace StateDemo{    class Program    {        static void Main(string[] args)        {            Context context = new Context(new ConcreteStateA());            context.Request();            context.Request();            context.Request();            Console.ReadKey();        }    }}

　　以上是对状态模式的简单介绍，其使用场景是： 当一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态。

　　本篇文章状态模式至此，谢谢您收看我的博客。