我必须为应用程序实现事件驱动的状态机。以下是要求：
状态机应接收事件：
一个状态应执行一个或多个操作（每个操作使用不同方法的状态类）。
内部事件在状态的操作方法内生成，并且将导致：
外部事件在应用程序外部生成，并且将导致：
[状态/操作在很多情况下是有时间限制的。
我有一个很好的主意，但是我如何实现状态机，我无法想到任何有效的机制来实现
我可以考虑保留一些我可以根据计时器/或外部事件设置的变量，然后在操作中的每个重要步骤都检查该变量。但是我不相信这种策略。另外，我不想细化我的操作，因为那样会有很多我不喜欢的操作。另外，将有多个线程执行多个状态机。
[如果您拆分操作并检查一些“ break-operation-variable”，则可以实现诸如协作调度程序之类的东西。就我个人而言，这是一个坏主意。
将每个“单个”操作拆分为一个（长）子操作列表，听起来要好得多。
但是我这边有更普遍的观察：
状态机的典型想法是，每个操作将继续运行，直到它“真正”完成为止，通常称为运行完成（RTC）。如果您在某处中断执行，当前状态是什么？状态机是否可以执行其他任何操作，就像继续执行当前正在运行的作业一样？答案一定不是！如果您认为自己能够在状态机中停止事务并在其间做一些其他工作，则可以打开设计梦m。
这时的问题是，为什么您想在状态机中中断事务，因为您无法执行任何依赖事务完成的事情？
但是，如果您“仅”想要做一些与当前活动事务无关的事情，则它不再是状态机本身设计的一部分。现在我们正在谈论一些与状态模式无关的调度！如果是这种情况，请寻找一些不错的调度程序。也许您的操作系统提供了您喜欢的所有必需功能，并且您能够将作业/状态处理程序拆分为多个任务或线程，并让操作系统调度程序完成其工作。
如果操作系统没有执行您喜欢的所有操作，则可以在其之上运行自己的调度程序。有很多这样的调度程序，通常与嵌入式设备开发有关，但也可以在PC OS上模仿或多或少的精确行为。
结论：您可以在状态机中拆分事务，然后切换上下文以对当前停止的事务执行unrelated操作。如果您还希望处理并行性，以期更好地扩展您的硬件，那么我宁愿使用一些线程池，但通常情况并非如此，因为所有内容切换和簿记都需要性能。但这取决于您。
对我来说还不是很清楚，what可能是具有状态模式实现的现实世界用例，该模式将事务分成多个部分。您可以提供一些更详细的信息吗？