状态模式与ENUM

Question

有时需要支持对象的状态。据我所知，有两种方法：

1. ENUM（SIMPLE）
2. 国家模式（OC原则）

显然需要将状态模式用于此类目的（我不确定）。

但阅读我经常面对的其他代码只是根本没有状态模式。 州模式是否有权力？

Answer 1

通常，ENUM方法涉及某种状态和转换的表（数组）。而设计模式与对象实现相同。

如果你没有引用带有ENUM的表方法，那么解决方案需要涉及一个大的if / else if块，这是非常难以管理的。参考下面的部分，我认为很明显这个特殊的解决方案是劣等的。

以下是我列为每个

的PRO和CON的内容

ENUM表格

优点：

• 由于表格在一个地方定义，因此更容易看到所有状态和转换

缺点：

• 状态和转换更多硬编码，需要更多代码更改才能扩展

设计模式

优点：

• 通过添加新对象，可以更轻松地扩展新状态。 （开放/关闭原则）
• 更容易确保状态处理所有信号，因为基类应将信号定义为抽象函数。
• 通过从州获得，更容易扩展特定国家的行为。状态模式应该将特定状态的行为放在一个对象中。

缺点：

• 通过查看代码更难以看到所有状态及其关系，因为它们分散在几个不同的类中。
• 最终可能会创建无法管理的对象数量。但是将其与相应的ENUM解决方案所需的相应if / else块进行比较。

Answer 2

为什么我们使用状态模式？删除条件逻辑复制，并用多态替换条件代码。

我们什么时候有条件逻辑复制？当我们有许多依赖于状态的动作时，你必须在每个动作中复制条件逻辑。当你有很多州时会变得很烦人。代码重复意味着您在添加新状态时应更新重复代码的每个副本。

因此，如果我没有重复的条件逻辑，我宁愿选择基于枚举的状态，而不是创建具有许多状态类的新类层次结构。有时我甚至更喜欢条件逻辑复制：例如当我有很多州，但只有很少的国家依赖行动。在这种情况下，我更喜欢有两个开关块而不是创建十个新类。