Java IDE建议将final类更改为Enum

在我的代码库中，我发现了这样一个类：

public final class Klass
{
   private static final long LONG_NUMBER = 10.0;

   private Klass() {}

   public static double calcSomethingUsingLongNumberAndParam(double param)
   {
     ...
     return something;
   }
}

我的IDE（IntelliJ IDEA）对此类提供了一个“改进”——将其更改为枚举。作为测试，我做了更改，并注意到没有对任何成员字段或方法进行其他重构，也没有对包含的静态方法进行任何调用

以下是生成的枚举：

public enum Klass
{
   ;
   private static final long LONG_NUMBER = 10.0;

   private Klass() {}

   public static double calcSomethingUsingLongNumberAndParam(double param)
   {
     ...
     return something;
   }
}

---

将最后一个类更改为枚举有好处吗？或者这是IDE的一个怪癖吗？

我最初的回答是肯定有好处的，枚举几乎在所有方面都取代了旧式的POJO单例（这是它的特例）。然而，这在一定程度上取决于所涉及的用例和实际代码。如果您只是将“final class”替换为“enum”，就像IDE在本例中所做的那样，那么好处是微乎其微的。另外，使用enum的一个主要好处是可以更好地检查有限值的类型，但是由于您似乎只使用一个数值，而且它是私有的，所以在这里没有任何好处

使用枚举与常量实用程序类的优点：

• enum可以用更少的代码实现几乎相同的功能—您不需要将函数或值声明为静态，也不需要私有构造函数，它们只是enum提供的现成样板
• 很明显，枚举并不意味着要实例化它们，而对于这样的类，可能需要进行更多的调查并从整体上查看其细节
• 对于这样一个类，更新代码的人如果没有注意到应该这样做的话，会更容易意外地弄乱单例模式

缺点：

• enum类本身实际上是最终的，但它们的内部设计取决于为enum值生成子类的可能性，因此它们对子类的保护在我看来有点粗糙

所以，如果这个类是作为外部库提供的接口的一部分，并且我们可以确信没有人会改变它自己的实现，那么它实际上比在这里使用枚举更安全。然而，如果这段代码是维护的（特别是由不同的开发人员维护的），并且任何代码都应该维护，我认为枚举有更多的优点，因为它更清楚地传达了它的意图。即使是我能想到的唯一的缺点，从子类化中移除保护，似乎也很边缘化，因为枚举实际上是最终的，不管怎样，在其定义类之外

有关枚举好处的更多讨论，请参阅。还有另一个关于在常量实用程序类（如您的类）中使用final关键字的好处的讨论：-我从讨论中得出的结论是，唯一的好处是明确禁止将其子类化，这无论如何都不会起作用，因为您无法覆盖静态内容

---

TLDR；使用enum替换的建议似乎是合理的，至少如果您省略了不必使用enum显式声明的内容。但是，这些差异与可读性和可维护性有关，而不是行为上的任何差异。

将此类更改为枚举没有任何直接的好处

它提供给您的唯一功能是省略私有构造函数（以及类上的

final

）

---

但您也需要一个单一的值（您不需要），或者只需要一个随机挂起的

将（空）值列表与类正文的其余部分分开。

您能显示生成的枚举是什么样子吗？实际上，您最好将其设置为

接口，因为它只有
静态
字段，没有成员方法。@daniu否，接口用于类型。出现
Klass
的实例意味着什么？（在有效的Java中有一条专门针对这一点的规定）。“枚举类本身不能是最终的，因为它们的内部设计取决于为枚举值生成子类的可能性。因此，你不能从子类中得到保护。”呃？不能扩展枚举或其值。@AndyTurner不能在枚举类定义之外扩展它们。它的成员确实扩展了枚举。但我确实是用一种令人困惑的方式写的。我会努力让它变得更好。。。