有限状态机是否应该具有“嵌套”状态机？有限状态机？

Question

您可以阅读我提出的这个问题关于机器应用程序的最佳架构的一些背景故事，尽管这对于帮助我解决这个问题并不是完全必要的。

我对有限状态机的理解（特别是对于实现）有点年轻，可能还缺乏一点，但我正在将此应用程序作为一个实现，并且我有一个需要嵌套 FSM 的地方。基本上，机器有一些高级状态（冷[又名刚刚启动]、归位、设置、准备运行、运行、报告、重置），但是当机器运行时，它需要有自己的小 FSM 实现（装载镜头、定位边缘、测量楔块、测量圆度和完成[可能还有更多内容]）。

我的问题是：我是否应该建立具有“嵌套状态”的功能，其中状态可以具有子状态列表，并且系统可以进入这些子状态并且这些子状态可以返回到父状态？或者我应该将 FSM 实现放在运行状态中，并将它们保留为两个不同的 FSM？或者你认为我正在做或想一些愚蠢的事情并且应该重新考虑？

欢迎提出想法、建议、批评和建议。

Answer 1

嵌套状态机是 UML 中的标准概念，因此这并不一定是愚蠢的。 更多详细信息请参见此处。

Answer 2

相反。能够嵌套 FSM 是一件好事。

人们不应该仅仅为了嵌套而嵌套 FSM，但有时 FSM 会变得相当大。如此大的绘图破坏了 FSM 模型的目的，因为它无法让您很好地了解内部工作原理。它变成了一个包含许多细节的巨大图表。

我认为你可以将它与课程进行比较。如果将所有内容都放入一个类中（更糟糕的是，将所有内容都静态化），那么拥有一个类的目的和优势就会消失。

FSM 也是如此。

举个例子，我的一位大学生使用 FSM 模拟了一只非常“现实”的狗的行为。他有一个巨大的模型，通过嵌套 FSM，我能够在短短几分钟内理解该模型。

所以，如果使用得当的话，这绝对是一件好事。

Answer 3

我只是想补充一点，嵌套状态（在 UML FSM 中）与将单独的 FSM“放入”运行状态中不同。

在真实的分层 FSM 中，事件首先被发布到当前的嵌套状态。如果该状态不处理它们，它们将被发布到父状态，依此类推。这允许人们“重构”从嵌套状态到父状态的常见状态转换。

Answer 4

我通过使用代表状态的枚举来解决这个问题。例如
兔子有生育状态。

ProcreationState 有一个枚举，

   enum State
{
    SettinNewSearchPosition,
    SearchingForFriend, 
    MovingTowardsFriend,
    EstablishingFriendship,
    Mating
}

在状态更新方法中，我只是检查它所处的状态并采取相应的操作。
我想这限制了该系统的整体能力。我经验不足，所以我尝试一下。对此方法的任何反馈都值得赞赏。

Answer 5

嵌套状态机是状态机理论的一个非常关键的组成部分，状态机不流行的原因，特别是在 Java 世界中，是状态爆炸问题，正如所讨论的 此处。

随着您的业务案例不断发展并变得复杂，状态数量增加，这将成为维护的噩梦。

嵌套状态机是具有分而治之模式的工具，可以防止这种困境，在我看来，它是成功状态机设计的必要组成部分。

如果您想查看实现示例，可以在我的博客中找到这些示例 blog1 博客2。