Question

观看后：The Clean Code Talks -- Inheritance, Polymorphism, & Testing

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

Answer 1

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

特别是不，所有switch语句都可以替换。状态机实际上是一个很有意义的情况。我在解析时经常使用状态机。当然，这可以通过设计模式和类多态来完成。但它更多（很多）更多的代码，它执行相同的工作，只是更慢，它不是更简单的可读性，它是一个只需要在一个地方，没有任何代码回收的解决方案。在这里使用子类只是没有优势。

然后再次，这是一个例外。通常，子类化通常是支持它的语言中更好的解决方案。

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

Answer 2

这不是枚举是邪恶的，而是切换声明。在C++ FAQ Book中对此进行了长时间的讨论，但要点是：除了有限的区域 - 例如对来自设备寄存器的数据的解释 - 一个大的开关梳子表明您正在使用数据来区分子类型。取而代之的是，您应该只使用子类型，获得编译器的帮助以保持其正确，并且还意味着当您（不可避免地）更改案例集时，编译器将自动添加新案例。

Answer 3

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

枚举很好。

Answer 4

我毫不犹豫地打电话给任何邪恶的。这是一个“你想要设计多么沉重”的问题。

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

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

Answer 5

“这是否意味着枚举在OO设计中是”邪恶的“，应该用多态来消除？”

一般

switch / enum构造可以是多种多态结构中的任何一种：状态和策略是最常出现的两种常见结构。

Answer 6

我认为当值已知时，枚举非常有用＆amp;少数几个此外，Enums在某种程度上被命名为常量。

枚举没有任何其他状态存储（除了它的值）当您具有不同的条件状态（并且条件需要更多状态而不是依赖于单个变量）时，多态性将会有所帮助。

我们是否应该始终支持多态性而不是枚举？

6 个答案: