6

我从State 模式的典型实现中收集到的是：

问题： 表示一个对象O，其行为根据其当前状态而改变。
解决方案：
1. 让对象O中的另一个对象S表示状态 2. 对象S将调用O的相应操作 3. 对象S将决定对象O的下一个状态

我关心的主要是#3. 状态转换表基本上分布在所有状态中。我已经看到这些解决方案变得非常繁琐，难以快速管理。这些状态不是指标，而是包含太多关于状态机的信息。
即使#2困扰我，我想这是相当合理的（摩尔机器。）我看到的唯一问题出现在错误修复/调试期间：代码导航/理解变得困难，直到将所有状态映射提交到内存。

下面的实现会更精确吗？
将状态表示为枚举，对象根据枚举所持有的值决定动作。它们位于一个表（δ，状态转换函数）中，该state transitions表是当前状态到下一个状态的映射。这state transition table也包含要执行的操作（Mealy machine）

4

1 回答 1

1

我不知道你为什么认为状态模式只能代表摩尔机器。

void SleepingState::alarm()
{
    kick_alarm_clock();
    set_state(new GrumpyState());
}

我们根据状态 (SleepingState) 和事件 (alarm) 选择输出 (kick_alarm_clock)，这使它成为 Mealy 机器。

您的替代方案确实有效且受欢迎（还有其他替代方案）。由于几种方法都足以实现机器逻辑，因此您根据“设计”或个人品味的其他考虑做出决定。更喜欢 State 模式的设计原因可能是您认为您会经常添加新状态，或者如果某些状态看起来足够相似以保证继承关系。我倾向于选择美学：仅当机器相当密集时我才使用状态模式 - 即大多数 { state, event } 对都有非平凡的动作和转换。如果机器相当稀疏，我会为所有的空方法感到尴尬。

于 2011-03-07T19:50:40.910 回答