64 | 状态模式：游戏、工作流引擎中常用的状态机是如何实现的？

精选留言(35)

• 

  张先生丶

  关于课堂讨论，可以在接口和实现类中间加一层抽象类解决此问题，抽象类实现状态接口，状态类继承抽象类，只需要重写需要的方法即可

  2020-03-30

  

   15
• 

  J.D.

  Flutter里引入了Bloc框架后，就是非常典型的状态模式（或是有限状态机）。https://bloclibrary.dev/#/coreconcepts

  2020-03-30

  

   6
• 

  李小四

  设计模式_63:
  # 作业
  组合优于继承
  - 即使不需要，也必须实现所有的函数
  >>> 最小接口原则，每个函数拆分到单独的接口中
  
  - 新增事件要修改所有状态实现
  >>> 观察者模式，用注解动态地把事件函数注册到观察队列中。
  
  # 感想
  看到状态接口类中直接使用了`obtainMushRoom()`这样具体的事件函数，感觉很不舒服。就像结尾的讨论，所有的状态类必须实现所有事件函数，新增一种事件状态接口和实现都要改。。。

  2020-03-30

  

   4
• 

  小晏子

  课后思考：要解决这个问题可以有两种方式1. 直接使用抽象类替代接口，抽象类中对每个时间有个默认的实现，比如抛出unimplemented exception，这样子类要使用的话必须自己实现。2. 就是还是使用接口定义事件，但是额外创建一个抽象类实现这个接口，然后具体的状态实现类继承这个抽象类，这种方式好处在于可扩展性强，可以处理将来有不相关的事件策略加入进来的情况。

  2020-03-30

  

   3
• 

  下雨天

  课后题
  最小接口原则
  
  具体做法:状态类只关心与自己相关的接口，将状态接口中定义的事件函数按事件分类，拆分到不同接口中，通过这些新接口的组合重新实现状态类即可！

  2020-03-30

  

   3
• 

  Monday

  实际上，上面的代码还可以继续优化，我们可以将状态类设计成单例，毕竟状态类中不包含任何成员变量。但是，当将状态类设计成单例之后，我们就无法通过构造函数来传递 MarioStateMachine 了，而状态类又要依赖 MarioStateMachine，那该如何解决这个问题呢？
  
  实际上状态类可以设计为单例，MarioStateMachine也可以通过函数的参数方式传入，但是这样做的优势是什么呢?
  

  2020-04-01

  

   2
• 

  jaryoung

  查表法中代码 this.score = actionTable[stateValue][eventValue]; // 61 line
  是否修改成 this.score += actionTable[stateValue][eventValue]; 才是正确呢？

  2020-04-01

  

   2
• 

  test

  课堂讨论：给新增的方法一个默认实现。

  2020-03-30

  

   2
• 

  Geek_Zjy

  课后作业，与过滤器上的解决方法一样:
  ……
  针对这个问题，我们对代码进行重构，利用模板模式，将调用 successor.handle() 的逻辑从具体的处理器类中剥离出来，放到抽象父类中。这样具体的处理器类只需要实现自己的业务逻辑就可以了。
  ……
  

  2020-03-31

  

   1
• 

  jaryoung

  代码中：
  public enum State {
      SMALL(0),
      SUPER(1),
      FIRE(2),
      CAPE(3);
  
      private int value;
  
      private State(int value) {
          this.value = value;
      }
  
      public int getValue() {
          return this.value;
      }
  }
  建议修改成：
  public enum State {
      SMALL(0),
      SUPER(1),
      CAPE(2),
      FIRE(3);
  
      private int value;
  
      private State(int value) {
          this.value = value;
      }
  
      public int getValue() {
          return this.value;
      }
  }
  不然查表法会有索引的问题呢，希望争哥改一下哈。

  2020-03-31

  

   1
• 

  攻城拔寨

  多写个抽象类默认实现接口，实现类继承抽象类就行了

  2020-03-31

  

   1
• 

  Geek_54edc1

  思考题，可以用回调来替换接口，状态机类的方法增加一个回调对象的入参

  2020-03-30

  

   1
• 

  Jxin

  1.解决方法的话，java可以用接口的def函数解决，也可以在实现类和接口间加一个def实现来过度。但这都是不好的设计。事实上接口def函数的实现是一种无奈之举，我们在使用接口时应依旧遵循其语意限制？而非滥用语言特性。
  
  2.所以上诉解决方案，个人认为最好的方式就是细分接口包含的函数，对现有的函数重新归类，划分成不同的接口。实现时以实现多接口的方式去组合出目标实现。这也是接口隔离的体现。

  2020-03-30

  

   1
• 

  Frank

  打卡 今日学习状态模式，收获如下：
  状态模式通过将事件触发的状态转移和动作执行，拆分到不同的状态类中，来避免分支判断逻辑。与策略模式一样，状态模式可以解决if-else或着switch-case分支逻辑过多的问题。同时也了解到了有限状态机的概念，以前在看一些资料时遇到这个概念，之前不太理解这个状态机时干嘛用的，通过今天的学习，理解了状态机就是一种数学模型，该模型中有几个状态（有限的），在不同的场景下，不同的状态之间发生转移，在状态转移过程可能伴随着不同的事件发生。
  对于课堂讨论，有两种方法：1. 在实现类和接口中间定义一层中间类，中间类来实现接口，中间类中的方法都时空实现，实现类继承中间类，有选择性的覆写自己需要的方法。之后修改了接口，只需要修改中间类即可，这种方式引入了中间类，使类个数变多，一旦接口中的抽象方法变多，中间类相应的方法也随着变多，这种思路不是很优雅。2. 使用在模版模式那一节课中提到的回调方法。

  2020-03-30

  

   1
• 

  业余爱好者

  （一直觉得状态机是个非常高大上的东西，心中一直有疑问，今天才算是基本弄懂了。）
  
  对于一个全局对象的依赖，当做方法参数传递是个不错的设计。像之前提到的servlet中的过滤器的过滤方法中，参数就有FilterChain这一对象。一个方法需要依赖（广义）一个对象，无非来自于对象属性和方法自身。前者叫做组合，后者叫做依赖。在接口设计中，由于没有属性一说，所以只能通过参数传递了。这样看来，说是设计，实际上是不得已而为之啊（还能怎样啊）。
  
  一直分不清状态模式和观察者模式，两者不都是状态变化之后触发一定的动作吗？

  2020-03-30

   1

   1
• 

  Tommy

  老师，状态机模式怎么防止状态回退呢？

  2020-03-30

   2

   1
• 

  Panmax

  查表法示例代码的 executeEvent 方法最后一行有误：
  应将：this.score = actionTable[stateValue][eventValue];
  改为：this.score += actionTable[stateValue][eventValue];

  2020-04-04

  

  
• 

  Hubbert伟涛

  不懂就要问，评论中对第二题课后题“所有的状态类都要做相应的修改”使用了模板方法的，想不出要怎么实现。使用抽象类继承，然后默认都抛出一个方法未实现的异常即可，简单易懂。但是使用模板方法这个我想不出要怎么实现。请指教

  2020-04-04

  

  
• 

  进击的前端er

  我有个前端组件，很适合这个模式，我正在尝试重构，发现代码缩减量可能达到50%以上，而且更容易理解

  2020-04-03

  

  
• 

  亢（知行合一的路上）

  老师讲状态模式，对比三种实现，之前项目中用过方法三，也是在用方法一的过程中，觉得太繁琐了，容易出错后才使用的。但对方法二，没有使用过，竟然也不知道。自己学知识不全面，仅仅为了使用、解决眼前的问题，学到的非常肤浅，没能抓到本质。感谢老师！

  2020-04-01

  

  