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

时间:2013-02-24 20:36:13

标签: java constants

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


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

4 个答案:

答案 0 :(得分:26)

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

相比之下,拥有与它们相关的类相关的常量是一种更具可扩展性和可读性的设计。

答案 1 :(得分:4)

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

因此,不考虑样式 - 单独的类,属性文件或嵌套在类中 - 我倾向于遵循domain driven design - 如果常量集只属于特定类(实体),则嵌套常数;如果概念涉及域模型中的多个实体,请随意将其作为单独的实体。

请记住,自Java 5以来,您可以随时使用enums

答案 2 :(得分:3)

单独的常量类不是面向对象的设计。在OO中,类(或接口)表示契约,并且仅包含常量的类不定义任何契约。

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

class SomeApplicationClass
implements ScrollPaneConstants  // Incorrect, import ScrollPaneConstants instead

答案 3 :(得分:-5)

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

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

相关问题