有限状态机模式 - 一个真实的模式？

Question

是否可以通过应用状态机模式来改进所有编写的代码？

我正在开发一个项目,这是一个可怕的,可怕的,错误的,破碎的意大利面条代码.我从这个博客中复制了Martin Fowler的示例状态机代码,并将整个垃圾堆转换为一系列语句.字面上只是一个国家,事件,过渡和命令的列表.

我无法相信这种转变.代码现在很干净,而且很有效.当然我之前已经了解过State Machines,甚至已经实现了它们,但在Martin Fowler的例子中,模型/配置的分离是惊人的.

这让我觉得我所做过的几乎所有事情都可以通过某种方式从这种方法中受益.我希望在我使用的每种语言中使用此功能.也许这应该是语言级别的功能.

有人认为这是错的吗？或者任何人都有不同模式的类似经历？

Answer 1

有限状态机(FSM),更具体地说是域特定语言(DSL),通过用专门语言描述解决方案,可以更容易地将问题与特定解决方案域匹配.

State Machine模式的局限性在于它本身构成了一种编程语言,但您必须编写自己的执行,测试和调试工具; 以及任何维护者必须学习的东西.您已将代码的复杂性转移到复杂的FSM配置中.偶尔,这很有用,但肯定不是普遍的.

而且由于任何冯诺依曼计算机本身都是FSM,所以当然任何程序都可以这种方式重铸.

Answer 2

意大利面条代码永远不是正确的答案.模式擅长清理意大利面条代码,但只要经过深思熟虑的设计就能达到同样的效果.

关于状态机问题:我个人认为它们非常有用.对于我创建的面向公众的应用程序,我重构使用状态图(我认为与状态机相同)并注意到您提到的好处.它是一个非常有用的抽象,因为它允许您将处理事件的关注分离到一个单独的组件中.有了这个,bug就会消失,因为状态图隐含地知道用户可以在哪里做什么,并且因为事件只在正确的地方处理,所以你不能真正执行无效的操作.此外,使用状态图允许我简化代码,因为我可以将所有事件处理代码从它所在的地方拉出来并将它放在它应该位于的一个地方 - 换句话说,其他组件不是因为它们上面还有事件处理程序而变得复杂.

一张图片值得一千个作品 - 这是我想出的设计:

有了这个,谁看就知道究竟该应用程序的行为在一个较高的水平.很难打破这一点,因为就像我说的那样,你无法进入无效状态,因为事件处理程序可以准确地控制你可以去的地方; 如果你可以进入无效状态,它的实现错误很容易修复.此外,代码清理的好处是巨大的.例如,使用状态图表,每当我进入任何暂停状态时,我都可以执行诸如停止时钟,在板上放置掩码等操作.它在一个地方有几行代码- 因为当我进入子状态时暂停图表首先通过父状态.如果没有状态图,我将不得不在处理事件的任何地方执行该代码.

我不知道它是否需要是一个语言级别的功能,但拥有一个良好实现的框架是很好的.