我们应该总是支持多态性而不是枚举吗？

看完之后:清洁代码会谈 - 继承,多态和测试

我检查了我的代码并注意到一些switch语句可以重构为多态,但我也注意到我只使用带枚举的switch语句.这是否意味着枚举在OO设计中是"邪恶的",应该用多态性消除？

首先,Java实际上有很多可以多态使用的枚举.我不是Java程序员,所以其他人当然可以给出一个很好的例子(我不能).此外,考虑到多态性通常只是矫枉过正.我也刚刚看过这个话题,这很棒,但它只提供指导方针,没有银弹.

所有陈述都可以被替换,这尤其不正确switch.状态机实际上是一个很有意义的情况.我在解析时经常使用状态机.当然,这可以通过设计模式和类多态来完成.但是它有更多(更多)代码,它执行相同的工作,只是更慢,它不是更容易阅读,它只是在一个地方需要的解决方案,没有任何代码回收.在这里使用子类只是没有优势.

然后,这是一个例外.通常,子类化通常是支持它的语言的更好解决方案.

编辑:我注意到这可能会引起争议.当然,有很多很好的解决方案可以封装解析,从正则表达式到解析器生成器框架(如Antlr).除了微不足道的情况之外,这些都是更好的解决方案.但是,我使用低级代码(显然不是Java)工作很多,不支持正则表达式,解析器生成器也会产生开销.

这不是枚举是邪恶的,它是转换语句.在C++常见问题解答书中对此进行了长时间的讨论,但要点是:除了有限的区域 - 例如对来自设备上的寄存器的数据的解释 - 一个大的开关梳子表明你'重新使用数据来区分子类型.取而代之的是,您应该只使用子类型,获得编译器的帮助以保持其正确,并且还意味着当您(不可避免地)更改案例集时,编译器将自动添加新案例.

class Sunday extends DayOfWeek {}
class Monday extends DayOfWeek {}
class Tuesday extends DayOfWeek {}
class Wednesday extends DayOfWeek {}
class Thursday extends DayOfWeek {}
class Friday extends DayOfWeek {}
class Saturday extends DayOfWeek {}

枚举很好.

我毫不犹豫地称之为邪恶.这是一个"你想要设计多么沉重"的问题.

在某些方面,枚举/开关很好.设置类层次结构是问题所不总是需要的开销.但案例陈述中的代码越多,可能性就越大,是的,也许你应该朝着更重的方向前进.

我的经验是几年前我为一堂课写的编译器.我的室友与我同班,我们以两种截然不同的方式接近它.我采取了重型OO方法,充满了多态性.他使用枚举和工会采取了重C方法.他的代码是我的LOC大小的1/2,他的代码更快编译,他的代码工作.他的代码很灵活,因为它没有过度设计.这对我来说在软件设计方面是一个宝贵的教训.