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

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

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

myCar.setColour(Colour.RED);

其中，

RED

是

color

类中的颜色常量

---

拥有大量常量的最佳实践是什么？它们应该位于主文件的顶部，还是拥有一个纯静态、公共且可读取的

ProgramConstants

类是明智的做法？

我更喜欢将常量放入逻辑上属于它们的类中

---

不要像

ProgramConstants

那样将不相关的常量放入类中，因为您可能会创建一堆混乱的常量，这将很难维护。

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

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

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

拥有大量常量的好做法是什么？它们应该位于主文件的顶部，还是拥有一个ProgramConstants类

放置常数的位置取决于常数的类型

JDK中的

Integer

类有一个名为

minu VALUE

的常量，该常量定义了int的最小值。

Character

类还定义了一个名为

minu VALUE

的常量，该常量定义了char的最小值

将上述方法与使用两个常量定义全局

wrapperstants

class/enum的方法进行比较，这两个常量分别是

CHAR\u MIN\u VALUE

和

INT\u MIN\u VALUE

。您将很快为其他数据类型向该文件添加更多常量。。（

LONG\u minu\u VALUE

，

FLOAT\u minu\u VALUE

等等…）

如果还要定义

最大值

，会发生什么情况？看看你的班级爆炸的速度有多快？可读性呢。

WrapperConstants.CHAR\u MIN\u VALUE

是否比

Character.MIN\u VALUE

更可读？不是真的

在与之相关的类中定义常量是一种方法。也就是说，并非所有常量都属于

Java

classes/interfaces/enum。某些常量（例如错误消息）最好放在消息包/属性文件中。

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

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

“常量是否应该在它们自己的文件中？”

同样，不。广义地说，有三种类型的常量，它们需要以稍微不同的方式进行分组

常量是内部实现细节的一部分，它们属于使用它们的实现代码附近

公共API常量。这是构成API公开公共契约一部分的常量，它们属于正在定义的API附近

程序的系统配置。这些常量属于系统的引导代码

---

类级别，用于在该类中使用常量。在一组类中使用常量的程序级。程序级的定义是什么？在主类内部还是外部？我认为最好的做法是首先不要有大量常量：）可能重复@biziclop大量常量不是问题。这些常量只有放在单个文件中时才会看起来很大。JDK有太多的常量，如果你计算它们，你可以说常量的数量是“大的”。（仅包装类就占10+个常量）。问题是将大量常量放入单个文件中。即使常量是相关的，也不应将它们放入单个文件中。Java中的包装器类是在它们自己的类文件中而不是在

wrapperstants

文件中定义相关常量的一个很好的例子。