创建一个包含大量静态字段的常量类可以吗？答案

【问题标题】：Is it OK to create a Constants class with large number of static fields?创建一个包含大量静态字段的常量类可以吗？
【发布时间】：2012-12-24 16:32:24
【问题描述】：

假设我有一个包含 200 多个静态字段的常量类：

class AnimalConstants {
  static final int AARDVARK = 1;
  static final int ANTELOPE = 2;
  static final int BEAR = 3;
  ...
  ...
  static final int ZEBRA = 200;
}

谁能解释一下使用这些类是否会对性能和内存造成任何负面影响。
如果将类更改为接口（例如 SwingConstants）并由某些类实现，是更好还是更糟？
如果我将常量实现为 Enum 类会更好还是更糟？

【问题讨论】：

看到你的用例，也许你应该看看enums
在您首先编写了一个易于维护的版本并分析您的应用程序以确定您有性能问题之前，甚至不要关心性能。即使您有 20 年的性能调优系统经验，您仍然应该衡量而不是猜测。

标签： java oop class constants

【解决方案1】：

当然enum 实现比一堆int 常量更笨重，但使用enum：

您不需要硬编码 Animals 的实际值（在您的情况下），以后可以更改
您不需要硬编码动物的总数，您可以简单地遍历所有动物
带有此枚举参数的方法将被正确理解（foo(Animal animal) 优于 foo(int animal)）
您可以稍后为您的 enum 值添加其他功能，例如内部价值isMammal

【讨论】：

【解决方案2】：

我不认为影响性能或内存。

我认为这与代码的可读性、保持常量接近使用它们的位置以及对问题的基本理解等有关。

我宁愿声明常量接近他们已经习惯的位置。我相信他们更容易理解的方式。 P>

如果你声称 200+ 的实常数真的相关，我会感到惊讶。如果是，它们就属于一个地方。如果不是，我会说应该将它们分成更小的部分，并在更靠近使用它们的地方声明。

我敢打赌，如果知道的话，会有比您人为的示例更多的上下文来改变响应。

当然，枚举很棒。不过先看看我的其他 cmets。

【讨论】：

那么，我不应该太担心使用大常量吗？我在我的项目中使用常量和枚举。大约 80%-20%。
“所以我不应该太担心” - 你从哪里得到的？是的，我认为你应该担心。我不相信您的用例需要 200 个常量。
实际上，我正在开发一个交易 API 项目，该项目引发了我的问题发布。 AnimalsConstants 只是帮助解决我的问题的抽象。
200+ 个常量是交易符号吗？它们属于数据库，而不是 Enum 或接口。

【解决方案3】：

对于您的 vars（动物类型），我建议您使用 Enumerator 而不是类。随着使用它的 var 数量，它不应该成为性能问题，因为您只使用 int 原语。如果任何 var 是一个类，那么就会出现问题，因为它们需要更多的内存来维护它们的结构。我希望能澄清你的疑问（对不起英语不好，我有点生锈了）

【讨论】：

【解决方案4】：

如果将类更改为接口（例如 SwingConstants）并由某些类实现，是更好还是更糟？

--> 那将是Constant Interface Pattern。如果我们将接口用于常量并且它由所有类实现，但如果您正在开发 API，则就像您在公开您的实现细节一样。上面的 wiki 链接很好地解释了这一点。

在这两种方法（接口或类）中，我建议使用最终类，创建常量并在必要时为常量执行static import。

如果我将常量实现为 Enum 类是更好还是更糟？

--> 使用枚举，这将是最好的方法。

【讨论】：

【解决方案5】：

更改已编译到另一个类中的任何值可能需要完整构建。

附录：请参阅Is it possible to disable javac's inlining of static final variables? 以获得更彻底的检查。

【讨论】：

【解决方案6】：

是的，可以创建大量常量。很难讨论负面影响，因为我们不知道任何替代方案，因为我们没有您的功能要求。

但请放心，编译器的编写可以很好地与人类编写的代码配合使用。拥有一堆字段可能会没问题。

我觉得常量可以很好用，从JDK7开始就可以用在switch case中，你可以和==比较，变量名可以提供信息。

枚举可以更好吗？是的，它可以。探索枚举的特性，看看是否有什么吸引你的地方

【讨论】：