design-patterns - 状态机和状态模式的实现有什么区别？

Question

我想知道状态机是否只是工作中的状态模式，还是这两者之间实际上存在差异？

我找到了这个 article with the bold title "the state design pattern vs state machine"但在一天结束时，他只说状态模式使状态机过时，但与状态模式的实现相比，他并没有描述究竟什么是状态机。

Answer 1

我向我的同事描述这种差异的方式是，状态模式是许多独立封装状态的更加分散的实现，而状态机则更加单一。状态机的单体性质意味着单个状态将更难在不同的机器中重用，并且更难将状态机分解为多个编译单元。另一方面，这种单片设计允许更好地优化状态机，并允许许多实现在表中的一个位置表示所有转换信息。这尤其适用于负责状态机架构或功能的人员不精通实现它的编程语言的情况。请记住，许多工程和数学专业的学生已经了解了状态机，但很少或没有受过教育。编程领域。与一页又一页的状态模式相比，向这些类型的人展示转换、 Action 和守卫的表格要容易得多。

虽然这篇文章实际上读得很好，但我在几个方面不同意作者的观点:

“当您使用面向对象的编程语言时，没有理由再使用状态机”如果您对执行速度有任何要求，这绝对不是真的。

作者的实现特别短或简单，或者它比 boost statecharts 数码相机需要更少的维护的想法取决于您的用例和个人品味，但不能一概而论。 http://www.boost.org/doc/libs/1_55_0/libs/statechart/doc/tutorial.html#IntermediateTopicsADigitalCamera

请注意，切换状态需要分配!这会扼杀速度。这可以通过将所有状态放置在彼此相邻的缓冲区中以节省一两个缓存未命中来解决。但是，这需要对 Authors 示例进行重大更改。

还要注意，未处理的事件不能像在静态状态机中那样被内联和优化掉，因为在状态模式下，它们位于动态间接层之后。根据您的要求，这也是一个潜在的效率杀手。

从维护的角度来看，应该注意记录未处理的事件不能从具有状态模式的一个中央超状态完成。此外，添加新的事件类型/处理程序函数需要向所有状态添加一个函数!我不认为维护友好。

我也更喜欢在表格中查看所有转换，而不是查看每个状态的内部工作原理。作者是对的，添加状态更容易，但只是非常简单，例如使用 boost 状态图，我只需要将状态添加到其父子状态列表中，这是唯一真正的区别。

在速度不是问题并且状态机的层次结构很可能保持平坦的情况下，我确实使用状态模式。作者是正确的，与状态机相比，状态模式的初始实现通常更容易，并且通常更多的程序员应该使用更多的状态机。

状态模式的一个论点是它允许实现“开放关闭”状态机，其中状态机可以在库中定义，然后由用户扩展，据我所知，这在主流状态机中是不可能的构架。