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

Question

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

---

我从 C 到 Java，在 C 中我只会创建一个.h文件，在其中定义常量#define

Answer 1

出于文体原因，不赞成使用专用文件中的常量。拥有一个专门用于常量的类可以鼓励开发人员将越来越多的不相关（未记录？）常量添加到一个慢慢膨胀失控的文件中。

相比之下，将常量与它们相关的类关联起来是一种更具可扩展性和可读性的设计。

Answer 2

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

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

请记住，从那以后Java 5，您确实可以使用enums。

Answer 3

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

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

class SomeApplicationClass
implements ScrollPaneConstants  // Incorrect, import ScrollPaneConstants instead

Answer 4

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

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