我们应该总是偏爱多态性而不是枚举吗?

首先,Java实际上有很多可以多态使用的枚举。我不是Java程序员,所以其他人肯定可以举个好例子(我不能)。同样,考虑多态性常常是多余的。我也刚刚看过这个演讲,它很棒,但它只提供了指导,没有什么灵丹妙药。

不 真的 switch 很

编辑:我注意到这可能会引起争议。当然,有很多很好的封装解析的解决方案,从正则表达式到解析器生成器框架,比如Antlr。它们没有什么问题,除了一些琐碎的问题,这些都是更好的解决方案。但是,我经常使用低级代码(显然不是Java代码),在这些代码中不支持正则表达式,解析器生成器也会产生开销。

并不是枚举是邪恶的,而是switch语句。关于这一点,报纸上有很长的讨论 C++ FAQ Book ,但要点是:除了有限的区域——例如,对来自设备寄存器的数据的解释——一个大的开关梳表明您正在使用数据来区分子类型。取而代之的是,您应该只使用子类型,获得编译器的帮助以保持其正确性,这也意味着当您(不可避免地)更改案例集时,编译器将自动添加新案例。

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 {}

枚举很好。

我不愿打电话给任何人 . 这是一个“你想制造多大重量”的问题。

枚举/开关很好-在某些区域。设置类层次结构是一种开销,但问题并不总是需要这种开销。但是case语句中的代码越多,就越有可能,是的,也许你 我们正朝着更重的方向前进。

我的经典经验是几年前为一个类编写的编译器。我的室友和我上同一门课,我们用两种截然不同的方式来学习。我采取了一种很重的OO方法,充满了多端性。他采用重C方法,使用枚举和联合。他的代码大约是我的1/2大小,他的代码编译速度更快,他的代码 . 他的代码很灵活,因为它 过度设计。这对我来说是一堂宝贵的软件设计课。

通常

开关/枚举构造可以是许多多态结构中的任意一种: 状态 策略

此外,枚举在某种程度上是命名常量。

当您有不同的条件状态时(条件需要更多的状态,而不是依赖于单个变量),多态性将非常有用。