这有点难回答,因为实际用例非常模糊,但这里有一些可能的技术:
1. 为生产 + 上电、测试 + 上电、生产 + 关机、测试 + 关机创建单独的状态。根据状态组合的复杂性和数量,这可能会迅速膨胀。
优点:直接明了。
缺点:混乱,不易扩展,如果某些状态逻辑在多个实例之间共享,则需要进行复制粘贴(因此不易维护)。
2. 使用分层状态机(HFSM),即如果您可以定义各种状态组之间的某种分层关系,则特定状态的实现将是一个独立的状态机。
因此,在您的示例中,您将拥有一个生产/测试状态机,每个状态机都将在内部实现自己的空闲/上电/关机/工作状态机。
优点:比选项1更易读。
缺点:假设子状态应共享某些通用登录信息,仍将涉及复制粘贴。
3. 拥有2个并行状态机,一个处理生产/测试状态,另一个处理空闲/上电/关机/工作状态,并使用某种黑板或共享内存在状态机之间通信。
在您的示例中,您的代理或系统将是上述状态机的容器,并依次处理它们。生产/测试机器将向共享内存写入一些状态,其他机器将从中读取并相应地分支其状态逻辑。
优点:可以在不同状态之间共享代码。
缺点:可以在不同状态之间共享代码...好吧,说真的,强调共享代码并不总是一个好主意(但这是一个完全不同的哲学讨论)。只需确保正确评估共享代码量与唯一代码或路径量之间的比例,以便不会得到一个包含2个完全不同代码路径的巨大类。
4. 我知道这是一个常见做法,但请考虑FSM是否是您的应用程序中表示状态和执行的适当方法。同样,没有足够的上下文来深入探讨这个问题,而且这个问题本身就是一个哲学上的辩论 - 但请保持开放的心态,考虑其他解决方案。