作为FSM构建整个程序的好设计？

Question

我已经使用像这里的FSM /下推自动机方法构建了一个解析器（它很有效！）C++ FSM design and ownership 它允许我优雅地退出，并在解析器阶段出现问题时向用户输出有用的错误消息。

我一直想知道在我的程序的其余部分完成这项工作的好方法，当然，解析器的方法在我脑海中浮现......

我会让每个对象成为一个状态，它有一个单独的event（）函数，它有一个switch语句，根据我的执行阶段调用对象特定的函数。我可以使用特定于对象的枚举来跟踪它，并使代码更具可读性（case parser比case 5更具可读性）。这将允许我关闭我创建的状态的下推树（在我的另一个问题中使用m_parent*方法）。

这是一个好的设计（强制一切都在FSM模式下）吗？有没有更好的方法，它会有多复杂（我发现FSM很容易实现和测试）？

感谢您的建议！

PS：我知道boost有一些可能需要的东西，但我想限制外部依赖，特别是在boost上。 c ++ 0x虽然没问题（但我觉得这里不太相关）

Answer 1

您正在做的有点像在程序中构建（简单）虚拟机。 FSM往往非常适合某些受限制的问题，如lexing和parsing，正如您可能已经注意到的，您可以“免费”获得相当多的日志记录和错误管理。

但是，如果你试图将FSM模式应用于所有东西（这对于包含很多状态的GUI程序来说很难，你通常不希望这些状态变成显式状态），你会去意识到你还需要设备调试你的FSM（因为C ++调试器不会理解你的状态和事件）和设施链接和重用状态（因为状态不会是OO级别的构造）。如果您想将代码交给其他人，他或她将需要额外的培训才能成功使用您的FSM。您是否想要为多个应用程序保留一个FSM引擎？如果是这样，您将如何处理版本控制和升级？

使用正确的工具来完成正确的工作。每种方法都有其优点和缺点。您的解决方案增加了另一层复杂性：您可以用更多C ++方式处理日志记录和错误处理。如果您对编写C ++代码不满意，可以考虑使用其他现有语言，而不是仅在您理解的情况下构建FSM语言。

Answer 2

大多数人会使用继承而不是switch / case / default。然而，强迫一切成为一种方式的想法本质上是错误的。您应该始终按照自己的优点来处理每个必需的功能。

Answer 3

您可以随时查看boost。