今天是星期天，照着深入浅出设计模式中的状态模式，有如下心得：

发现，状态模式它的应用范围是解决一个对象的状态问题（并且这个状态的主体的状态是循环变化的，可以由A变成B，然后B变成C，然后C再变成A等等），而我们平常接触的单据的状态，是不可以用状态模式去解决问题的。

第二，状态，并不简单是一个标识字段，对于它的客户端来说，它应该包括行为，因为行为改变状态，并且这种行为与状态的主体共享一个接口，当主体操作这些行为时，这些动作将转分为状态执行。

比如我们就以书上的例子说明

 public interface IAction
    {
        /// <summary>
        /// 存款
        /// </summary>
        /// <param name="amount"></param>
        void Deposit(decimal amount);
        /// <summary>
        /// 取消
        /// </summary>
        /// <param name="amount"></param>
        void WithDraw(decimal amount);

        /// <summary>
        /// 计算利息
        /// </summary>
        void PayInterest();

    }

所有状态以及主体都需要实现这样的接口，并且主体向外发布 这些接口服务。

另外，状态应该从实现了刚才的接口的对象之中继承，也就是状态们都来自于一个抽象的共离基类

  public abstract class BaseStatue : IAction
    {
        protected  void StateChangeCheck()
        {
            if (balance < 0)
                account.State = new RedState(this);
            else if (balance < lowerLimit)
                account.State = new SliverState(this);
        }
    }

这个抽象类应该把这个状态的变化封装到这些，由它去检测状态的变化。

这样我们每个状态的变化都会同时调用上面的这段判断函数。

另外，每个状态不仅包括了需要主体提供而来的转发服务，而且还需要包括这个状态的前一个状态，因为状态的转换是依据前一个状态而进行的。