《设计模式之美》状态模式：游戏、工作流引擎中常用的状态机是如何实现的？

王争《设计模式之美》学习笔记

• 在实际的软件开发中，状态模式并不是很常用，但是在能够用到的场景里，它可以发挥很大的作用。
• 状态模式一般用来实现状态机，而状态机常用在游戏、工作流引擎等系统开发中。

什么是有限状态机

• 有限状态机，英文翻译是Finite State Machine，缩写为FSM，简称为状态机。
• 状态机有3个组成部分：状态（State）、事件（Event）、动作（Action）。
• 其中，事件也称为转移条件（Transition Condition）。事件触发状态的转移及动作的执行。不过，动作不是必须的，也可能只转移状态，不执行任何动作。

文中举例

• 超级马里奥
• 马里奥形态的转变就是一个状态机：
  • 其中，马里奥的不同形态就是状态机中的“状态”
  • 游戏情节（比如吃了蘑菇）就是状态机中的“事件”
  • 加减积分就是状态机中的“动作”
  • 比如，吃蘑菇这个事件，会触发状态的转移：从小马里奥转移到超级马里奥，以及触发动作的执行（增加100积分）

状态机实现方式一：分支逻辑法

• ，最简单直接的实现方式是，参照状态转移图，将每一个状态转移，原模原样地直译成代码。这样编写的代码会包含大量的 if-else 或 switch-case 分支判断逻辑，甚至是嵌套的分支判断逻辑，所以，我把这种方法暂且命名为分支逻辑法。
• 对于复杂的状态机来说，这种实现方式极易漏写或者错写某个状态转移。除此之外，代码中充斥着大量的 if-else 或者 switch-case 分支判断逻辑，可读性和可维护性都很差。如果哪天修改了状态机中的某个状态转移，我们要在冗长的分支逻辑中找到对应的代码进行修改，很容易改错，引入 bug。

状态机实现方式二：查表法

• 除了用状态转移图来表示之外，状态机还可以用二维表来表示。在这个二维表中，第一维表示当前状态，第二维表示事件，值表示当前状态经过事件之后，转移到的新状态及其执行的动作。
• 查表法的代码实现更加清晰，可读性和可维护性更好。当修改状态机时，我们只需要修改 transitionTable 和 actionTable 两个二维数组即可。实际上，如果我们把这两个二维数组存储在配置文件中，当需要修改状态机时，我们甚至可以不修改任何代码，只需要修改配置文件就可以了。

状态机实现方式三：状态模式

• ，如果要执行的动作并非这么简单，而是一系列复杂的逻辑操作（比如加减积分、写数据库，还有可能发送消息通知等等），我们就没法用如此简单的二维数组来表示了。这也就是说，查表法的实现方式有一定局限性。
• 状态模式通过将事件触发的状态转移和动作执行，拆分到不同的状态类中，来避免分支判断逻辑。

代码示例

public interface IMario {
    //所有状态类的接口
  State getName();
  //以下是定义的事件
  void obtainMushRoom();
  void obtainCape();
  void obtainFireFlower();
  void meetMonster();
}

public class SmallMario implements IMario {
   
  private MarioStateMachine stateMachine;
  public SmallMario(MarioStateMachine stateMachine) {
   
    this.stateMachine = stateMachine;
  }
  @Override
  public State getName() {
   
    return State.SMALL;
  }
  @Override
  public void obtainMushRoom() {
   
    stateMachine.setCurrentState(new SuperMario(stateMachine));
    stateMachine.setScore(stateMachine.getScore() + 100);
  }
  @Override
  public void obtainCape() {
   
    stateMachine.setCurrentState(new CapeMario(stateMachine));
    stateMachine.setScore(stateMachine.getScore() + <