状态模式

今天写个状态机，吧。

先假设我们的角色只有两个状态：攻击状态和受击状态。

一般情况下，我们的代码可能是这样的：

    public enum State
    {
        Attack,
        BeHit,
    }

    public class Player
    {
        State state;
        
        public Player()
        {
            state = State.Attack;
        }

        public State GetPlayerState()
        {
            return state;
        }

        public void SetPlayerState(State state)
        {
            this.state = state;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Player player = new Player();
            if(player.GetPlayerState() == State.Attack)
            {
                //干Attack时的事儿
                //....

                //当受击时，切换到BeHit状态
                player.SetPlayerState(State.BeHit);
            }
            else if(player.GetPlayerState() == State.BeHit)
            {
                //干BeHit时的事儿
                //....

                //当受击结束，切换到Attack状态
                player.SetPlayerState(State.Attack);
            }
        }
    }

简单明了，客户根据角色当前的状态，当满足对应条件时，切换到新的状态。

好了，现在让我们为角色添加一个新状态：眩晕状态。

我们先在枚举中添写，然后。。。就是在最后一个else if后面添加一个else if，写上眩晕状态时需要做的事儿。

这还不是最恐怖的，最口怕的是，还要在之前的两个状态里，添加对眩晕状态的条件判断。

当添加的状态足够多。。。太容易出错了。

这是因为客户和每个状态的具体实现耦合在了一起。

下面我们看一个新的结构：

    public interface PlayerState
    {
        void Attack();
        void Behit();
    }

    public class AttackState : PlayerState
    {
        Player player;

        public AttackState(Player player)
        {
            this.player = player;
        }

        public void Attack()
        {
            //攻击
        }

        public void Behit()
        {
            player.SetState(player.GetBeHitState());
        }

    }

    public class BeHitState : PlayerState
    {
        Player player;

        public BeHitState(Player player)
        {
            this.player = player;
        }

        public void Attack()
        {
            player.SetState(player.GetAttackState());
        }

        public void Behit()
        {
            //受击
        }
    }
    
    public class Player
    {
        PlayerState attackState;
        PlayerState beHitState;

        PlayerState state;

        public Player()
        {
            attackState = new AttackState(this);
            beHitState = new BeHitState(this);

            state = attackState;
        }

        public void Attack()
        {
            state.Attack();
        }

        public void BeHit()
        {
            state.Behit();
        }

        public PlayerState GetAttackState()
        {
            return attackState;
        }

        public PlayerState GetBeHitState()
        {
            return beHitState;
        }

        public void SetState(PlayerState state)
        {
            this.state = state;
        }
    }

这个结构一个很明显的特点：篇幅长。
一本正经的胡说八道。。

最明显的一个特点：把每个状态封装进一个类！

这种结构，客户不知道也不关心状态机的具体行为，他甚至不知道状态机当前处于什么状态！这样，客户只拥有一个状态实例，他只需要在执行每个行为时，调用状态实力的对应方法就好了，至于状态的细节（当前状态做什么事儿，状态的切换），交给每个状态自己做就好了，客户与状态的实现解耦。

现在，当我们再想要添加一个新的状态时，就可以肆无忌惮，这个状态做好自己该做的就好了，不担心会影响到别的状态，也不会被别的状态影响！

一句话总结状态模式：把每一个状态封装成独立的类。