如何正确使用状态模式？

Question

在我的编程经验中，我遇到了一些状态模式的实现，并且做了一些。我见过它们在各种场景中使用(主要是UI和解析)。问题是，在快速开发的压力下，所有这些代码都变成了难以维护和可理解的代码块。我正在考虑重构其中一个，但是我很难在网上找到好的资源。网上有许多简单的状态模式示例，但我需要更多的深度资源。

所以我在找：

• 实现状态模式时常见缺陷的示例以及如何避免它们，
• 正确完成状态模式的实际示例(如在某些开源项目/框架中)
• 欢迎有国家模式的个人经验。

谢谢您抽时间见我

Answer 1

@Ivan:在层次状态机网站上有很多资源可供使用。Miro Samek写了大量关于这种设计模式的文章，并提供了许多有用的信息。

应当感兴趣的一些条款：

• 面向状态的程序设计(Samek) (pdf)
• 层次状态机--设计的一种基本重要方法(Samek) (pdf)
• C/C++ (Samek)中的实用状态图 (链接到google-book)
• 面向状态的编程(由Asher Sterkin编写) (pdf)

在Mealy和Moore描述的平面FSM状态图上使用HSM的最大好处是，层次结构造成了责任的分离。子状态只需要处理那些它们明确设计用来处理的条件--未处理的事件被传递给父状态，如果父状态没有明确地设计来处理它，那么它就被传递给下一个更高的父级，等等。它允许您创建小型的、可管理的状态机，每个机器都有一个单一的用途--一个可以容纳在单个对象中的状态机。在添加新特性或添加新类时，它们只需要处理自己的一小部分世界，并将未处理的事件传递给各自的父级。

如果实现正确，您将得到一个具有低圈复杂度的健壮程序，这很容易根据需要修改或升级。

Answer 2

只是我的两分钱，状态模式总是很难保持，因为没有编码的人很难理解它。我通常回到函数/方法指针的旧标准数组中，就像我在以前的C经验中所做的那样。您只需为行/列构建一个带有状态/信号的函数指针的二维数组。更容易理解。您有一个类来管理它，并委托其他类来处理复杂性.

my2c

Answer 3

大多数情况下，状态模式设计中的状态处理的状态比一个或多个状态(或状态的子状态)更难维护。

如果一个州有任何类型的选择在那里，它主要处理多个州。

我需要很大的纪律来保持州的清洁。

解决这一问题的一个可能方法是制造更复杂的状态状态本身(HSM)。这使得它在上层的可读性要高得多，因为它必须处理较少的状态。