状态模式与ENUM

Question

有时需要为对象的状态提供支持.据我所知,有两种方法:

1. ENUM(SIMPLE)
2. STATE模式(OC原理)

很明显,需要将状态模式用于此类目的(我不确定).

但阅读我经常面对枚举的其他代码根本不是状态模式.州模式有权力吗？

Answer 1

通常,ENUM方法涉及某种状态和转换的表(数组).而设计模式与对象实现相同.

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

以下是我列出的每个PRO和CON的内容

ENUM表

优点:

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

缺点:

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

设计模式

优点:

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

缺点:

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

Answer 2

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

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

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