什么时候应该在自己的文件中定义常量？答案

【问题标题】：When should constants be defined in their own files?什么时候应该在自己的文件中定义常量？
【发布时间】：2015-07-17 10:28:50
【问题描述】：

我注意到一些项目喜欢将常量存储在自己的文件中，即全局和主程序循环中使用的常量可能会使主文件混乱，因此他们可能希望将它们放在其他地方，然后引用/导入文件/类。

我了解，在编写 OOP 类时，您希望将所有常量保留在类文件的头部，以便可以静态引用它们：

myCar.setColour(Colour.RED);

其中RED 是Colour 类中的颜色常量。

拥有大量常量的好实践是什么，它们应该只是在主文件的顶部，还是以任何方式拥有一个 ProgramConstants 类是明智的纯静态、公开且可供阅读？

【问题讨论】：

在该类中使用常量的类级别。在一组类中使用常量的程序级别。
程序级别的定义是什么？在主课内还是课外？
我认为最好的做法是首先不要有大量的常量:)
What is the use of interface constants? 的可能重复项
@biziclop 大量常量不是问题。常量仅在放入单个文件时看起来很大。 JDK 有太多的常量，如果你计算它们，你可以说常量的数量是“大”的。（仅包装类就占了 10 多个常量）。问题是将大量常量放入一个文件中。

标签： java class constants

【解决方案1】：

拥有大量常量的最佳做法是，它们应该位于主文件的顶部，还是以任何方式拥有一个 ProgramConstants 类是否明智

关于在何处放置常量的决定应取决于常量的类型。

JDK 中的Integer 类有一个名为MIN_VALUE 的常量，它定义了一个int 的最小值。 Character 类还定义了一个名为 MIN_VALUE 的常量，它定义了字符的最小值。

将上述方法与使用两个常量即CHAR_MIN_VALUE 和INT_MIN_VALUE 定义全局WrapperConstants 类/枚举的方法进行比较。您很快就会在此文件中添加更多用于其他数据类型的常量。（LONG_MIN_VALUE、FLOAT_MIN_VALUE 等等...）

当您还想定义MAX_VALUE 时会发生什么？看看你的班级能以多快的速度爆发？可读性怎么样。 WrapperConstants.CHAR_MIN_VALUE 是否比 Character.MIN_VALUE 更具可读性？不是真的。

在与它们相关的类中定义常量是 IMO 的方法。也就是说，并非所有常量都属于Java 类/接口/枚举。一些常量（例如错误消息）最好放在消息包/属性文件中。

【讨论】：

【解决方案2】：

我更喜欢将常量放入逻辑所属的类中。

不要把不相关的常量放到ProgramConstants这样的类中，因为你可以创建一堆乱七八糟的常量，这将变得难以维护。

【讨论】：

即使常量是相关的，也不应该放在一个文件中。 Java 中的包装类是在它们自己的类文件中而不是在WrapperConstants 文件中定义相关常量的一个很好的例子。

【解决方案3】：

不，您不应该将所有常量放在主类的顶部或它们自己的类中，它们应该放在与它们逻辑关联的任何类中。

问题是，如果程序员看到一个通用的地方来放置一些东西，例如常量文件，那么他们会将所有常量放在这里以保持模式，而他们应该将它们放在正确且合乎逻辑的位置。拥有一个大的常量文件会使使用常量变得更加困难，因为它们实际上是未分类的并且破坏了模块化。作为架构师，您的职责是避免设计带有此类陷阱的系统。

因此，例如，假设您有与 Java 应用程序的运行相关的系统属性，那么在您的主类中一定有几个这样的常量。如果你最终在你的主类中有太多，那么将它们移到同一个包中的 SystemProperties 类中。当程序员需要几个常量供自己使用时，例如示例中的颜色，他们应该创建自己的 Colors 类，该类放入与包含这些常量的功能相关联的包中。

【讨论】：

【解决方案4】：

“是否应该在一个文件中定义所有个常量？”

绝对不是。在除了最小的程序之外的所有程序中，这都会产生单点争用/混乱。非常类似于“全局变量”反模式。

“常量应该在自己的文件中吗？”

再次，不。从广义上讲，常量分为三种类型，每种类型都需要以各自略有不同的方式进行分组。

常量是内部实现细节的一部分，它们属于使用它们的实现代码。
公共 API 常量。这是构成 API 公开合同一部分的常量，它们属于正在定义的 API。
程序的系统配置。这些常量属于系统的引导代码。

【讨论】：