这不包括你可能在大学里做过的有限状态机。
我想知道谁必须创建一个,为什么?
制造这台机器最困难的方面是什么?
是的,很多。基本上,出于性能原因,我不得不手动实现词法分析器。其他个人用途是在 GUI 设计中,其中 FSA 控制了与用户的交互流程。
制造这样的机器一点也不难。更改它们是因为 FSA 的至少一部分结构被严格地嵌入在代码中。状态模式有助于缓解其中一些转换——但不是全部。
很多次!
通信系统中使用的大多数协议栈都是作为状态机实现的。CSTA 呼叫模型就是一个很好的例子。
此外,大多数嵌入式系统本质上都是状态机。
基本上,任何必须对现实世界中的事件做出反应的系统都是作为状态机实现的良好候选者。
状态机最困难的事情是在没有最新文档的情况下理解它们的作用。他们倾向于将错误修复得面目全非。
当然,我设计并制造了一个涡轮调速器来控制小型涡轮机、泵和电机。它是带有 DSP 芯片的嵌入式设备。它具有停止、启动、运行、超速测试等状态,然后在运行状态下有几种状态,以涵盖其他控制可能性。
在我的例子中,关于状态机管理最困难的部分是设计一个干净的转换,特别是当状态可以有子状态时。对于涡轮调速器,这意味着必须在转换之间平滑地调整速度输出(执行器)。其他挑战与用户界面(按钮和 7 段 LED 显示屏)以及它们如何与状态机交互有关。所以最终有一个主控制状态机、一个相关的用户界面状态机和一个相关的通信状态机(不允许在涡轮机运行时写入某些值)。
我在各种其他项目中使用过状态机,一些嵌入式和一些标准软件,以及从通信到用户界面软件。
如上所述,FSA 的目的只是一步一步地进行,所有处理(和状态更改)都在一个循环中处理。而且,当流程发生变化时,很容易进入下一个合乎逻辑的步骤。
是的,它们很容易做到,25 年来我经常使用它们。
我也有。我通常创建小型 FSM(状态很少),因为较大的 FSM 会成为维护的噩梦,但有时 FSM 对于给定任务来说是一种非常简单而优雅的设计。
作为一个真实的例子,我创建了一个小工具来修复某种类型的文件。与用户只有 3 或 4 种可能的交互路径:
创建状态机使这些路径变得明显且易于实现。