5

在我正在使用的 C# 解决方案中,应用程序逻辑的核心通过(非常好的)无状态库实现为状态机。业务逻辑的其他部分在许多其他类中建模,用于应用程序显示的不同区域功能,但这是推动底层应用程序状态主要变化的部分。

尽管每个状态转换本身都非常简单(通知事件、设置 eventArgs、监听其他事件……)并且我在适用时使用子状态,但对我来说它开始看起来太大了。我知道这不是一个精确的衡量标准,但是如果您查看并考虑子状态,您最终可能会发现它们本身可能是不同的状态机。

是否有一种明显的方法可以让我用无状态构建单独的子状态机(可以这么说),将每个状态机映射到一个不同的类(和文件)?

我想到的第一个阻塞问题是(尤其是第二个):

  1. 一体式状态机触发所有状态更改的事件:拆分后,每个状态机将触发各自的触发器。所以最好有一个外观收集所有事件并为客户端重新触发它们,以便隐藏许多状态机(毕竟它们是客户端的实现细节)。

  2. 无状态子状态负责在状态/子状态链上以及向下的冒泡触发。因此,例如对于A具有子状态的给定状态,可以定义一个触发器(在一个地方A的配置),它将使状态机离开A,无论A我们将处于哪个子状态。这如何与单独的子状态机一起工作?

4

1 回答 1

2

正如您所提到的,定义好的子状态对于抽象大型状态机的各个部分非常有帮助。如果您将超状态及其子状态的定义以及所有守卫和进入/退出/转换操作放在其自身的一个类中,这也会很有帮助。

同意您对第 1 点的建议。客户端需要将其视为 1 个状态机。

关于第 2 点,我建议通过内部触发器在子状态机和超级状态机之间定义一些接口。

让我们称您的超级状态机A和您的子状态机BA将触发诸如StartB 之类的事件,它将B从某种空闲状态移动到InProgress状态,即运行子状态机。同时A进入某种WaitingForB状态。当B完成其子进程时,它将在A上触发BComplete 之类的事件。然后, A将继续其其余过程。

您可以让AB共享同一组可能的触发器,但B也可以定义自己的(较小的)触发器集或在适合其抽象的子流程的级别上。如果B不需要响应与 A 相同的完整触发器集,认为从你的一体式状态机A中抽象出一个子状态机B是最有意义的。

于 2015-06-01T07:11:46.797 回答