Design patterns 状态模式是否准确地表示了方法？

我从s的典型实现中得出以下结论：

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

我主要关心的是

#3

。状态转换表基本上分布在所有状态中。我看到这些解决方案变得非常麻烦，很快就无法管理。这些状态不是指示符，而是保存了太多关于状态机的信息。
尽管

#2

困扰着我，但我想这是相当合理的（.）我所看到的唯一问题出现在bug修复/调试期间：在将所有状态映射提交到内存之前，代码导航/理解变得很困难

以下实现是否更精确？

---

将状态表示为枚举，对象根据枚举持有的值决定操作。

状态转换

位于一个表（δ，状态转换函数）中，该表是当前状态到下一状态的映射。这个

状态转换表

还包含要执行的操作（）

我不知道为什么您认为状态模式只能表示摩尔机器

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

我们根据状态（SleepingState）和事件（alarm）来选择输出（kick_alarm_clock），这使它成为一台简单的机器

---

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

是的。这确实是一种模式。请修改标题以反映您的实际问题。您所描述的是实现状态机的另一种方式（从我所看到的情况来看也是很常见的），但它不是状态机模式（如GoF模式手册中提到的）+1，谢谢。更新了标题。我刚才提到了使用枚举的状态模式，也许你会发现一些有趣的东西。我只是说#2没有错，并不是说它只能代表摩尔机器+1用于

kick\u闹钟（）