问如何使用状态机处理多个状态？

EN

这一点很难回答，因为实际的用例非常模糊，但以下是一些可能的技术：

1. 为Production+Powerup、Test+Powerup、Production+Powerdown、Test+Powerdown创建单独的状态。这取决于状态的复杂性和组合数，它可能会很快爆炸。

优点:直率。

缺点:杂乱无章，不能很好地扩展，如果在实例之间共享一些状态逻辑，就会涉及到一些副本面点(因此，不太容易维护)。

1. 使用分层状态机(HFSM)，也就是说，如果您可以在各个状态组之间定义某种层次关系，那么特定状态的实现将是一个独立的状态机。

因此，在您的示例中，您将有一个生产/测试状态机，每个状态机都将在内部实现它自己的Idle/Powerup/Powerdown/Work状态机。

如果您仔细考虑，这实际上是选项1的更整洁的实现。

优点:比备选方案1更具可读性

缺点:假设子状态应该共享一些常见的登录，仍然需要复制粘贴。

1. 拥有两个并行状态机，一个处理生产/测试状态，另一个处理带有某种黑板或共享内存的Idle/Powerup/Powerdown/Work状态，以便在机器之间进行通信。

在您的示例中，您的代理或系统将成为上述状态机的容器，并依次处理它们。生产/测试机器将向共享内存写入某种状态，由另一台机器从中读取，并相应地将其状态逻辑分支。

优点:可以在不同的状态之间共享代码。

缺点:可以在不同的州之间共享代码..。好的，序列化，非常重要的是要理解共享代码并不总是一个好主意(但这是另一个复杂的讨论。只需确保正确地计算共享代码的数量和唯一的代码或路径的数量，这样就不会有一个实质上包含两个完全独立的代码路径的大型类。

1. 我知道这是允许的，但是考虑一下FSM是否是在应用程序中表示状态和执行的正确方法。同样，没有足够的上下文深入到这个问题上，而这一点本身就是一场复杂的辩论--但你也要对其他解决方案敞开心扉。

您的状态机“爆炸”的感觉在传统的“平面”FSM中非常典型(事实上，它通常被称为“状态转换爆炸”现象)。解决方法是使用分层状态机 (HSM)，它专门对抗传统有限状态机的“爆炸”。基本上，HSM允许您将具有类似行为的状态分组在一起(在更高级别的超级状态内)，从而重用相关状态之间的常见行为。这是一个非常强大的概念，导致更优雅和一致的设计。要了解有关分层状态机的更多信息，可以阅读文章“分层状态机简介”。

状态机可以与另一个状态机共享信号。因此，指示prod或dev的状态机可以向另一台发送信号。

实际上，如果状态机上只有两个状态，则可以为此使用一个变量。因此，您将有一个状态机，它将根据变量的值执行不同的工作。