使用枚举实现实用程序类和单例

Question

Peter Lawrey在他的博客上写了Two Uses of Enums that most people forget。

首先，我没有忘记 - 我甚至没有意识到：）

这些方法简洁明了 - 与更传统的实现相同方法的方法相比，除了简洁之外还有什么好处，例如将final类与private构造函数用于实用程序类？ / p>

此外，是否有任何问题（除了令人困惑的程序员不期待它）？

Answer 1

对于真实的枚举，使用enums似乎更直观。

Answer 2

我真的不同意该帖子中第一次使用enum。如果您想要一个不可实例化的实用程序类，只需给它一个私有构造函数。就这么简单，enum在我看到的那种情况下没有提供额外的好处。

在实用程序类中使用枚举用于单例是很好的，但我通常会尝试保留enum正在使用内部实现细节的事实。例如，请参阅Guava的Predicates类，该类使用enum来强制执行某些Predicate的{​​{1}}个实例，例如alwaysTrue()。但它不会向用户公开enum。

至于其他好处：是的，还有其他好处，例如内置的可串行化，并且每个类加载器绝对强制执行enum常量的单个实例，即使在反序列化时也是如此。

Answer 3

我在这两种情况下的第一直觉是他们是讨厌的黑客。

在单例的情况下，我认为你可以合理地论证，在枚举常量是第一类对象的语言中，单例和只有一个值的枚举在概念上没有区别。我仍然不确定我是否真的会使用这种技术，特别是因为单身模式因其他原因而非常不受欢迎。

使用实用类的枚举更难防御。没有概念上的理由将一组实用方法表达为枚举（可以说它们没有理由将它们表示为一个类，但这是另一个辩论）。似乎以这种方式实现实用程序方法的唯一理由是通过忽略已建立的约定来节省一点点类型。

Answer 4

除了对非枚举事物使用枚举的混淆问题之外，使用Enums for monletons与其他硬编码单例范围的方法具有相同的缺点，基本上它阻碍了测试并使继承或其他扩展变得困难。让单例范围由像Spring这样的工厂控制是一个更好的主意。

Answer 5

我不喜欢这种做法。枚举应该保持简单的枚举。它们最多应包含转换逻辑。将enum用作单例或接口看起来像是一个混淆代码。