为什么不建议将常量存储在单独的类中？

有人告诉我（我在其他一些地方已经看到过这种说法），不建议将常量存储在Java中的单独类中，以便在其他类中使用它们。但我没有看到任何地方为什么这样。我不应该将它们存储在自己的接口/类中的原因是什么？

我来自C到Java，在C中，我只创建一个.h文件，用#define定义常量

由于风格原因，专用文件中的常量不受欢迎。拥有一个专用于常量的类可以鼓励开发人员将越来越多的不相关（ 未记录的？ ）常量添加到缓慢失控的文件中。

相比之下，具有与它们相关的类相关的常数是更具可扩展性和可读性的设计。

因此，您可以成为工程师并测量常数和位置作为技术选择。当您使用性能关键系统或酷小片段时，这非常棒。然而，一旦您的应用程序趋于增长，就会越来越难以掌握代码中反映的业务需求和最终用户需求。

因此，不考虑样式 – 单独的类，属性文件或嵌套在类中 – 我倾向于遵循域驱动设计 – 如果常量集仅属于特定类（实体），则嵌套常量; 如果概念涉及域模型中的多个实体，请随意将其作为单独的实体。

并且请记住，自Java 5以来，您可以随意使用enums 。

单独的常量类不是面向对象的设计。在OO中，类（或接口）表示契约，而仅包含常量的类不定义任何契约。

另一个面向对象的考虑是单独的常量类鼓励滥用inheritance。 inheritance应该表明一个类完全遵守另一个类或接口定义的契约。 inheritance不应仅用于共享function或常量; 这就是public方法和领域的用途。因此，此代码不正确：

 class SomeApplicationClass implements ScrollPaneConstants // Incorrect, import ScrollPaneConstants instead

问题是他们应该完全在源代码之外生活。您应该使用Apache Commons Config之类的东西，或者至少从.properties文件加载。

我还要注意，我在合理的范围内解释“单身”。例如，对于存储在Google服务器上的所有Java开发人员，应该没有一个Config文件，其中包含用于修改的请求表单。您的整个代码库可能不应该完成; 但是，每个UOR或包装是合理的范围，并且是我在实践中使用的范围。