有限状态机

说到状态模式不得不提一下有限状态机。

一个事物，有多个状态但是数量有限，同一时间只能处在一种状态下，可以根据条件相互切换，就是有限状态机。

我们用游戏里的宝箱来举例子。

宝箱有三种状态，上锁，关闭，打开。

上锁状态时，我们需要消耗钥匙才可以打开宝箱拿走里面的道具，并且宝箱会进入打开状态。

如果我们没有要是，就会提醒我们需要钥匙才能打开，宝箱依然保持上锁状态。

我们消耗了要是打开了宝箱，但是我们的道具数量已经达到了上限，所以只能把道具放回宝箱里，但是锁已经开了，所以宝箱会进入关闭状态。

等我们消耗了道具以后再把道具取走，宝箱又会进入打开状态。

只是一个简单的宝箱逻辑，写起来还不是很复杂，如果是一个角色的控制器，角色拥有站立、行走、奔跑、跳跃、攻击、攀墙、射击等多个状态，case 的数量就会随着状态增加，并且会添加大量的if判断，增加 Trigger 函数的复杂度。

这时就可是使用状态模式。

状态模式

状态模式，将每个状态都封装成单独的类，在自己的内部处理逻辑，切换状态时切换引用的状态对象，从而执行对应状态的逻辑。

定义一个宝箱的状态接口，它仅有一个用来执行逻辑的函数。

再创建宝箱的状态类并实现状态接口。

最后修改宝箱类，将枚举改为宝箱状态接口类型，并提供一个触发函数和一个设置状态的函数。

触发函数用来执行宝箱的触发逻辑，当玩家与宝箱交互的时候调用这个函数，而它调用状态对象的触发函数来执行当前状态的逻辑。

修改状态的函数用来修改当前状态，主要给状态对象使用，状态对象在执行逻辑时根据情况调用宝箱的设置状态函数来修改宝箱的状态。

至此，便完成了状态模式的简单实现。

好处

那么这么做到底有什么好处呢？

假设我们的逻辑更复杂一些，每个状态都只需要在自己的类里面去增加变量或函数去处理，只需要关注自身所需要关注的事物。

坏处

但是也有坏处，这样做势必会增加结构上的复杂度，使用不当会造成结构和代码的混乱。

增加新的状态也要去其他的类里面修改代码来保证状态直接的切换。

参考

《游戏编程模式》