将整个程序构建为 FSM 的良好设计？
我已经使用 FSM/Pushdown Automaton 方法构建了一个解析器，如下所示（并且它有效！）： C++ FSM 设计和所有权 当解析器阶段出现问题时，它允许我优雅地退出并向用户输出有用的错误消息。
我一直想知道在程序的其余部分中完成此操作的好方法，自然地，解析器方法出现在我的脑海中......
我将使每个对象成为一个状态，它有一个 event() 函数，该状态具有根据我所处的执行阶段调用对象特定函数的 switch 语句。我可以使用特定于对象的枚举来跟踪这一点，并使代码更具可读性（case parser 比 case 5 更具可读性）。这将允许我关闭我创建的状态下推树（在我的其他问题中使用 m_parent* 方法）。
这是一个好的设计吗（强制一切都在 FSM 模式下）？有没有更好的方法，它会复杂多少（我发现 FSM 很容易实现和测试）？
感谢您的建议！
PS：我知道 boost 拥有人们可能需要的一切，但我想限制外部依赖，尤其是在 boost 上。 c++0x 虽然还可以（但我认为这里并不真正相关）
I have built a parser using a FSM/Pushdown Automaton approach like here (and it works, well!): C++ FSM design and ownership
It allows me to exit gracefully and output a helpful error message to the user when something goes wrong at the parser stage.
I have been wondering about a good way to get that done in the rest of my program, and naturally, the parser approach popped in my mind...
I would make every object a state, which has a single event() function that has a switch statement calling object specific functions depending on the stage of execution I am. I can keep track of that with object-specific enum's, and keep the code more readable (case parser is more readable than case 5). This will allow me to close off the pushdown tree of states I have created (using the m_parent* approach in my other question).
Is this good design (forcing everything in a FSM-mode)? Is there a better way, and how much more complicated will it be (I find the FSM pretty easy to implement and test)?
Thanks for the suggestions!
PS: I know boost has about everything one may ever need, but I want to limit external dependencies, especially on boost. c++0x is ok though (but not really relevant here I think)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
大多数人会使用继承而不是 switch/case/default。然而，强迫一切都以一种方式进行的想法本质上是错误的。您应该始终根据每个所需功能的优点来处理它。
Most people would use inheritance instead of switch/case/default. However, the idea of forcing everything to be one way is inherently wrong. You should always approach each required functionality on it's own merits.
您可以随时查看 boost 。
You can always take a look at boost.
你所做的有点像在你的程序中构建一个（简单的）虚拟机。 FSM 往往非常适合某些受限问题，例如词法分析和解析，并且正如您可能已经注意到的，您可以“免费”获得相当多的日志记录和错误管理。
然而，如果您尝试将 FSM 模式应用于所有内容（这对于 GUI 程序来说会很困难，因为 GUI 程序包含大量您通常不想将其设置为显式状态的状态），您将意识到您还需要调试 FSM 的工具（因为 C++ 调试器无法理解您的状态和事件）以及链接和重用状态的工具（因为状态不会是 OO 级别的构造）。如果您想将代码交给其他人，他或她将需要额外的培训才能成功使用您的 FSM。您是否想要为多个应用程序保留一个 FSM 引擎？如果是这样，您将如何处理版本控制和升级？
使用正确的工具完成正确的工作。每种方法都有其优点和缺点。您的解决方案又增加了一层复杂性：您可以用更多 C++ 风格的方式处理日志记录和错误处理。如果您对编写 C++ 代码不满意，您可以考虑其他现有语言，而不是构建只有您理解的 FSM 语言。
What you are doing is a bit like building a (simple) virtual machine in your programme. An FSM tends to be a good fit for some restricted problems such as lexing and parsing, and as you've probably noted, you can get quite a bit of logging and error management 'for free'.
However, if you try to apply the FSM pattern to everything (which is going to be tough for e.g. GUI programmes which contain quite a lot of state you normally wouldn't want to make into explicit states), you're going to realize that you also need facilities to debug your FSM (since the C++ debugger won't understand your states and events) and facilities to link and reuse states (since the states won't be OO level constructs). If you ever want to hand over your code to someone else, he or she is going to need additional training to use your FSM successfully. Are you going to want to keep one FSM engine for multiple applications? If so, how are you going to deal with versioning and upgrades?
Use the right tool for the right job. Every approach has its strengths and weaknesses. Your solution adds another layer of complexity: you can deal with logging and error handling in more C++-ish ways. If you're not happy with writing C++ code, you might consider other existing languages, rather than building an FSM language only you understand.