状态模式一般用来实现状态机，而状态机常用在游戏、工作流引擎等系统开发中。不过，状态机的实现方式有很多种，除了状态模式，比较常用的还有分支逻辑法和查表法。下面，我们就详细讲讲这几种实现方式，并且对比一下它们的优劣和应用场景。

什么是有限状态机？

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

下面，举个具体的例子来解释一下，在“超级马里奥”这款游戏中，马里奥可以变身为多种形态，比如小马里奥（Small Mario）、超级马里奥（Super Mario）、火焰马里奥（Fire Mario）、斗篷马里奥（Cape Mario）等等。在不同的游戏情节下，各个形态会互相转化，并相应的增减积分。比如，初始形态是小马里奥，吃了蘑菇之后就会变成超级马里奥，并且增加 100 积分。

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

状态机的实现方式

1. 分支逻辑法

实现状态机最简单直接的方式就是，参照状态转移图，将每一个状态转移，原模原样地直译成代码。但这样编写的代码会包含大量的 if-else 或 switch-case 分支判断逻辑，甚至是嵌套的分支判断逻辑。按照这个实现思路，上面示例的状态机代码实现如下：

  1. // 状态定义
  2. public enum State {
  3.     SMALL(0),    // 小马里奥
  4.     SUPER(1),    // 超级马里奥
  5.     FIRE(2),    // 火焰马里奥
  6.     CAPE(3);    // 斗篷马里奥
  8.     @Getter
  9.     private int value;
  11.     private State(int value) {
  12.         this.value = value;
  13.     }
  14. }
  16. // 马里奥的有限状态机
  17. @Getter
  18. public class MarioStateMachine {
  19.     private int score = 0;
  20.     private State currentState = State.SMALL;
  22.     // 吃蘑菇
  23.     public void obtainMushRoom() {
  24.         if (currentState.equals(State.SMALL)) {
  25.             this.currentState = State.SUPER;
  26.             this.score += 100;
  27.         }
  28.     }
  30.     // 获得斗篷
  31.     public void obtainCape() {
  32.         if (currentState.equals(State.SMALL) || currentState.equals(State.SUPER) ) {
  33.             this.currentState = State.CAPE;
  34.             this.score += 200;
  35.         }
  36.     }
  38.     // 获得火焰
  39.     public void obtainFireFlower() {
  40.         if (currentState.equals(State.SMALL) || currentState.equals(State.SUPER) ) {
  41.             this.currentState = State.FIRE;
  42.             this.score += 300;
  43.         }
  44.     }
  46.     // 遇到怪物
  47.     public void meetMonster() {
  48.         if (currentState.equals(State.SUPER)) {
  49.             this.currentState = State.SMALL;
  50.             this.score -= 100;
  51.             return;
  52.         }
  53.         if (currentState.equals(State.CAPE)) {
  54.             this.currentState = State.SMALL;
  55.             this.score -= 200;
  56.             return;
  57.         }
  58.         if (currentState.equals(State.FIRE)) {
  59.             this.currentState = State.SMALL;
  60.             this.score -= 300;
  61.             return;
  62.         }
  63.     }
  64. }
  66. public class ApplicationDemo {
  67.     public static void main(String[] args) {
  68.         MarioStateMachine mario = new MarioStateMachine();
  69.         mario.obtainMushRoom();
  70.         System.out.println("mario score: " + mario.getScore() + "; state: " + mario.getCurrentState());
  71.     }
  72. }

对于简单的状态机来说，分支逻辑这种实现方式是可以接受的。但是，对于复杂的状态机来说，这种实现方式极易漏写或者错写某个状态转移。除此之外，代码中充斥着大量的 if-else 或者 switch-case 分支判断逻辑，可读性和可维护性都很差。如果哪天修改了状态机中的某个状态转移，我们要在冗长的分支逻辑中找到对应的代码进行修改，很容易改错，引入 bug。

2. 查表法

上面这种实现方法有点类似 hard code，对于复杂的状态机来说不适用，而状态机的第二种实现方式查表法，就更加合适了。实际上，除了用状态转移图来表示之外，状态机还可以用二维表来表示，如下所示。在这个二维表中，第一维是当前状态，第二维是事件，值表示当前状态经过事件后，转移到的新状态及其执行的动作。
捕获.PNG
相对于分支逻辑法，查表法的代码实现更加清晰，可读性和可维护性更好。当修改状态机时，我们只需要修改 transitionTable 和 actionTable 两个二维数组即可。实际上，如果我们把这两个二维数组存储在配置文件中，当需要修改状态机时，我们甚至可以不修改任何代码，只需要修改配置文件就可以了。具体的代码如下：

  1. public enum Event {
  2.     GOT_MUSHROOM(0),
  3.     GOT_CAPE(1),
  4.     GOT_FIRE(2),
  5.     MET_MONSTER(3);
  7.     @Getter
  8.     private int value;
  10.     private Event(int value) {
  11.         this.value = value;
  12.     }
  13. }
  15. public class MarioStateMachine {
  16.     private int score = 0;
  17.     private State currentState = State.SMALL;
  19.     // 状态表
  20.     private static final State[][] transitionTable = {
  21.         {SUPER, CAPE, FIRE, SMALL},
  22.         {SUPER, CAPE, FIRE, SMALL},
  23.         {CAPE, CAPE, CAPE, SMALL},
  24.         {FIRE, FIRE, FIRE, SMALL}
  25.     };
  27.     // 动作表
  28.     private static final int[][] actionTable = {
  29.         {+100, +200, +300, +0},
  30.         {+0, +200, +300, -100},
  31.         {+0, +0, +0, -200},
  32.         {+0, +0, +0, -300}
  33.     };
  35.     public void obtainMushRoom() {
  36.         executeEvent(Event.GOT_MUSHROOM);
  37.     }
  39.     public void obtainCape() {
  40.         executeEvent(Event.GOT_CAPE);
  41.     }
  43.     public void obtainFireFlower() {
  44.         executeEvent(Event.GOT_FIRE);
  45.     }
  47.     public void meetMonster() {
  48.         executeEvent(Event.MET_MONSTER);
  49.     }
  51.     private void executeEvent(Event event) {
  52.         int stateValue = currentState.getValue();
  53.         int eventValue = event.getValue();
  54.         this.currentState = transitionTable[stateValue][eventValue];
  55.         this.score += actionTable[stateValue][eventValue];
  56.     }
  57. }

3. 状态模式

在查表法的代码实现中，事件触发的动作只是简单的积分加减，所以，我们用一个 int 类型的二维数组 actionTable 就能表示，二维数组中的值表示积分的加减值。但是，如果要执行的动作并非这么简单，而是一系列复杂的逻辑操作（比如加减积分、写数据库，还有可能发送消息通知等等），我们就没法用如此简单的二维数组来表示了。这也就是说，查表法的实现方式有一定局限性。

虽然分支逻辑法不存在这个问题，但它又存在前面讲到的其他问题，比如分支判断逻辑较多，导致代码可读性和可维护性不好等。实际上，针对分支逻辑法存在的问题，我们可以使用状态模式来解决。状态模式走的是更崇高的路线，它通过将事件触发的状态转移和动作执行，拆分到不同的状态类中，来避免分支判断逻辑。状态模式的代码实现如下：

  1. // 所有状态类的接口
  2. public interface IMario {
  3.     State getName();
  4.     // 以下是定义的事件
  5.     void obtainMushRoom();
  6.     void obtainCape();
  7.     void obtainFireFlower();
  8.     void meetMonster();
  9. }
  11. public class SmallMario implements IMario {
  12.     private MarioStateMachine stateMachine;
  14.     public SmallMario(MarioStateMachine stateMachine) {
  15.         this.stateMachine = stateMachine;
  16.     }
  18.     @Override
  19.     public State getName() {
  20.         return State.SMALL;
  21.     }
  23.     @Override
  24.     public void obtainMushRoom() {
  25.         stateMachine.setCurrentState(new SuperMario(stateMachine));
  26.         stateMachine.setScore(stateMachine.getScore() + 100);
  27.     }
  29.     @Override
  30.     public void obtainCape() {
  31.         stateMachine.setCurrentState(new CapeMario(stateMachine));
  32.         stateMachine.setScore(stateMachine.getScore() + 200);
  33.     }
  35.     @Override
  36.     public void obtainFireFlower() {
  37.         stateMachine.setCurrentState(new FireMario(stateMachine));
  38.         stateMachine.setScore(stateMachine.getScore() + 300);
  39.     }
  41.     @Override
  42.     public void meetMonster() {
  43.         // do nothing...
  44.     }
  45. }
  47. public class SuperMario implements IMario {
  48.     private MarioStateMachine stateMachine;
  50.     public SuperMario(MarioStateMachine stateMachine) {
  51.         this.stateMachine = stateMachine;
  52.     }
  54.     @Override
  55.     public State getName() {
  56.         return State.SUPER;
  57.     }
  59.     @Override
  60.     public void obtainMushRoom() {
  61.         // do nothing...
  62.     }
  64.     @Override
  65.     public void obtainCape() {
  66.         stateMachine.setCurrentState(new CapeMario(stateMachine));
  67.         stateMachine.setScore(stateMachine.getScore() + 200);
  68.     }
  70.     @Override
  71.     public void obtainFireFlower() {
  72.         stateMachine.setCurrentState(new FireMario(stateMachine));
  73.         stateMachine.setScore(stateMachine.getScore() + 300);
  74.     }
  76.     @Override
  77.     public void meetMonster() {
  78.         stateMachine.setCurrentState(new SmallMario(stateMachine));
  79.         stateMachine.setScore(stateMachine.getScore() - 100);
  80.     }
  81. }
  83. // 省略CapeMario、FireMario类...
  85. @Getter
  86. @Setter
  87. public class MarioStateMachine {
  88.     private int score;
  89.     private IMario currentState; // 不再使用枚举来表示状态
  91.     public MarioStateMachine() {
  92.         this.score = 0;
  93.         this.currentState = new SmallMario(this);
  94.     }
  96.     public void obtainMushRoom() {
  97.         this.currentState.obtainMushRoom();
  98.     }
  100.     public void obtainCape() {
  101.         this.currentState.obtainCape();
  102.     }
  104.     public void obtainFireFlower() {
  105.         this.currentState.obtainFireFlower();
  106.     }
  108.     public void meetMonster() {
  109.         this.currentState.meetMonster();
  110.     }
  111. }

其中，IMario 是状态的接口，定义了所有的事件。SmallMario、SuperMario、CapeMario、FireMario 是 IMario 接口的实现类，分别对应状态机中的 4 个状态。原来所有的状态转移和动作执行的代码逻辑，都集中在 MarioStateMachine 类中，现在，这些代码逻辑被分散到了这 4 个状态类中。

有一点需要注意，即 MarioStateMachine 和各个状态类之间是双向依赖关系。MarioStateMachine 依赖各个状态类是理所当然的，但是，反过来，各个状态类为什么要依赖 MarioStateMachine 呢？这是因为，各个状态类需要更新 MarioStateMachine 中的两个变量，score 和 currentState。

实际上，上面的代码还可以继续优化，我们可以将状态类设计成单例，毕竟状态类中不包含任何成员变量。但是，当将状态类设计成单例后，我们就无法通过构造函数来传递 MarioStateMachine 了，这里我们可以通过函数参数将 MarioStateMachine 传递进状态类。根据这个设计思路，我们对上面的代码进行重构。

  1. public interface IMario {
  2.     State getName();
  3.     void obtainMushRoom(MarioStateMachine stateMachine);
  4.     void obtainCape(MarioStateMachine stateMachine);
  5.     void obtainFireFlower(MarioStateMachine stateMachine);
  6.     void meetMonster(MarioStateMachine stateMachine);
  7. }
  9. public class SmallMario implements IMario {
  10.     private static final SmallMario instance = new SmallMario();
  11.     private SmallMario() {}
  12.     public static SmallMario getInstance() {
  13.         return instance;
  14.     }
  16.     @Override
  17.     public State getName() {
  18.         return State.SMALL;
  19.     }
  21.     @Override
  22.     public void obtainMushRoom(MarioStateMachine stateMachine) {
  23.         stateMachine.setCurrentState(SuperMario.getInstance());
  24.         stateMachine.setScore(stateMachine.getScore() + 100);
  25.     }
  27.     @Override
  28.     public void obtainCape(MarioStateMachine stateMachine) {
  29.         stateMachine.setCurrentState(CapeMario.getInstance());
  30.         stateMachine.setScore(stateMachine.getScore() + 200);
  31.     }
  33.     @Override
  34.     public void obtainFireFlower(MarioStateMachine stateMachine) {
  35.         stateMachine.setCurrentState(FireMario.getInstance());
  36.         stateMachine.setScore(stateMachine.getScore() + 300);
  37.     }
  39.     @Override
  40.     public void meetMonster(MarioStateMachine stateMachine) {
  41.         // do nothing...
  42.     }
  43. }
  45. // 省略SuperMario、CapeMario、FireMario类...
  47. @Getter
  48. @Setter
  49. public class MarioStateMachine {
  50.     private int score;
  51.     private IMario currentState;
  53.     public MarioStateMachine() {
  54.         this.score = 0;
  55.         this.currentState = SmallMario.getInstance();
  56.     }
  58.     public void obtainMushRoom() {
  59.         this.currentState.obtainMushRoom(this);
  60.     }
  62.     public void obtainCape() {
  63.         this.currentState.obtainCape(this);
  64.     }
  66.     public void obtainFireFlower() {
  67.         this.currentState.obtainFireFlower(this);
  68.     }
  70.     public void meetMonster() {
  71.         this.currentState.meetMonster(this);
  72.     }
  73. }

实际上，像游戏这种比较复杂的状态机，包含的状态比较多，我优先推荐使用查表法，而状态模式会引入非常多的状态类，会导致代码比较难维护。相反，像电商下单、外卖下单这种类型的状态机，它们的状态并不多，状态转移也比较简单，但事件触发执行的动作包含的业务逻辑可能会比较复杂，所以，更推荐使用状态模式来实现。