你有没有必要创建一个有限状态机？

Question

这不包括你可能为大学所做的有限状态机。

我想知道谁必须创建一个以及为什么？

创建机器最困难的方面是什么？

Answer 1

是的，很多。基本上，出于性能原因，我必须手动实施词法分析器。其他个人用途一直在GUI设计中，FSA控制了与用户的交互流程。

创建这样的机器并不困难。 更改它们是因为FSA的至少部分结构严格嵌入代码中。 state pattern有助于缓解其中的一些过渡 - 但不是全部过渡。

Answer 2

很多次！

通信系统中使用的大多数协议栈都是作为状态机实现的。 CSTA呼叫模型就是一个很好的例子。

大多数嵌入式系统本质上都是状态机。

基本上任何必须对现实世界中的事件作出反应的系统都是作为状态机实现的良好候选者。

状态机最困难的事情是了解在没有最新文档的情况下他们做了什么。他们倾向于将bug修复得无法识别。

Answer 3

当然，我设计并创建了一台涡轮调速器来控制小型涡轮机，泵和电机。它是一个带有DSP芯片的嵌入式设备。它具有停止，启动，运行，超速测试等状态，然后在运行状态下有几个状态可以覆盖其他控制可能性。

就我而言，关于状态机管理最困难的部分是设计一个干净的过渡，特别是当州可以有子状态时。对于涡轮调速器，这意味着必须在过渡之间平稳地调节速度输出（致动器）。其他挑战与用户界面（按钮和7段LED显示屏）以及它们与状态机的交互方式有关。因此，最终成为主控制状态机，相关的用户界面状态机和相关的通信状态机（在涡轮机运行时不允许写入某些值）。

我在各种其他项目中使用状态机，一些嵌入式和一些标准软件，以及从通信到用户界面软件。

Answer 4

如上所述，FSA的目的就是，从一步到另一步，所有处理（和状态变化）都在一个循环中处理。而且，当流程发生变化时，进入下一个逻辑步骤很容易。

是的，他们很容易做到，我经常使用它们超过25年。

Answer 5

我也有。我通常会创建小型FSM（几乎没有状态），因为较大的FSM会成为维护噩梦，但有时FSM对于给定任务来说是一种非常简单和优雅的设计。

作为一个真实的例子，我创建了一个小实用程序来修复某种类型的文件一次。用户只有3或4个可能的交互路径：

• 显示一条消息，选择文件（可能取消并重新开始），
• 修复文件（可能取消并退出并显示错误消息），
• 显示确认消息。

创建状态机使这些路径变得明显且易于实现。