我注意到一些项目喜欢将常量存储在自己的文件中，即全局和主程序循环中使用的常量可能会混乱主文件，所以他们可能会将它们放在别处，然后引用/导入文件/类。
据我所知，在编写OOP类时，您希望将所有常量保留在类文件的标题中，以便可以静态引用它们：
myCar.setColour(Colour.RED);
其中RED是Colour类中的颜色常量。
对于拥有大量常量的良好的做法是什么，如果它们只是位于主文件的顶部，或者以任何方式明智地拥有ProgramConstants类这纯粹是静态的，公开的，可供阅读吗？
答案 0 :(得分：6)
拥有大量常量的好习惯是，它们只是位于主文件的顶部，还是以任何方式明智地拥有ProgramConstants类
关于放置常数的位置的决定应该取决于常量的类型。
JDK中的Integer类有一个名为MIN_VALUE的常量，它定义了int的最小值。 Character类定义了一个名为MIN_VALUE的常量，它定义了char的最小值。
将上述方法与使用两个常量WrapperConstants和CHAR_MIN_VALUE定义全局INT_MIN_VALUE类/枚举的方法进行比较。您很快就会为此文件添加更多常量以用于其他数据类型..（LONG_MIN_VALUE，FLOAT_MIN_VALUE等等......）
当您还要定义MAX_VALUE时会发生什么？看看你班级爆炸的速度有多快？可读性如何？ WrapperConstants.CHAR_MIN_VALUE比Character.MIN_VALUE更具可读性吗？不是真的。
在与它们相关的类中定义常量是IMO的方法。也就是说，并非所有常量都属于Java类/接口/枚举。一些常量（例如错误消息）最好放在消息包/属性文件中。
答案 1 :(得分：1)
我更喜欢将常量放入逻辑上属于的类中。
不要将不相关的常量放入像ProgramConstants这样的类中，因为你可以创建一堆乱七八糟的常量，这将很难维护。
答案 2 :(得分：1)
不，你不应该将所有的常量放在主类的顶部或者他们自己的类中，它们应该进入与逻辑相关的任何类。
问题在于，如果程序员看到一个通用的地方放置某些内容，例如常量文件，那么他们会将所有常量放在这里以维护模式，而他们应该将它们放在正确和合理的位置。有一个大的常量文件使得使用常量变得更加困难，因为它们实际上没有被分类并且破坏了模块性。作为架构师，您应该避免设计具有这些陷阱的系统。
所以，例如，假设您拥有与Java应用程序运行相关的系统属性，那么在主类中一定有几个常量。如果最终在主类中有太多，则将它们移到同一包中的SystemProperties类中。当程序员需要几个常量供自己使用时，比如示例中的颜色，他们应该创建自己的Colors类，该类位于与包含这些常量的特征相关联的包中。
答案 3 :(得分：1)
“所有常量应该在一个文件中定义吗？”
绝对不是。在除了最小的程序之外的所有程序中，这将产生单点争用/混乱。非常类似于'全局变量'反模式。
“常量应该在他们自己的文件中吗？”
再一次，没有。从广义上讲，常量有三种类型，每种都需要按照自己略有不同的方式进行分组。