对属性键使用常量有什么意义？答案

【问题标题】：What's the point of using constants for property keys?对属性键使用常量有什么意义？
【发布时间】：2009-02-15 15:13:06
【问题描述】：

最近，我遇到了很多依赖“属性文件”进行配置的 Java 代码。但是代码不是使用普通的旧字符串文字，而是使用常量（静态最终字符串）来检索属性值。

我发现这种额外的间接级别很烦人，因为我需要在 EITHER 方向上执行两次查找。如果我从配置文件中观察到的属性开始，我必须首先搜索属性名称以找到 Java 常量，然后再次搜索以找到代码中对该常量的引用。如果我从代码开始，我必须先找到常量的实际值，然后才能确定配置文件中属性的值！

有什么意义？

我了解使用常量来引用资源包中的键的价值，通常是为了支持 i18n。我指的是简单的、非面向用户的配置值。我能想到的唯一原因是让以后更容易更改属性名称，但这个好处远不及恕我直言的烦恼，特别是考虑到全局搜索和替换的便利性。 p>

【问题讨论】：

【解决方案1】：

一方面，您不能在使用常量时错误地键入键而不会出现编译器错误。

【讨论】：

我同意“错字参数”在开发过程中具有一定的价值，但在调试生产问题时却没有。而且我认为适当的单元测试可以降低拼写错误的风险（更不用说生产问题了），所以间接的成本仍然大大超过了收益。

【解决方案2】：

如果需要在不重新编译的情况下更改值，则不可避免地需要进行一些重定向，但再做一次是非常愚蠢的，除非需要在多个地方引用键（这本身可能是关注点分离不佳的标志）。

键字符串应该具有足够的描述性，以至于它们不能与超出其范围（通常是类）的其他字符串发生冲突，并且在单个类中保持文字的唯一性既不复杂，也不太可能成为值得在单个块中声明的严重问题。因此（IMO）这种做法只是在不了解规则的初衷的情况下盲目遵守规则的人。

如果您需要向他们引用另一条准则来证明放松这一准则的合理性，我建议 KISS。

【讨论】：

【解决方案3】：

即使在简单的全局搜索和替换（这不是新事物）的日子里，使用常量也可以让您知道字符串仅用于该属性文件。这很好，因为：

在很多情况下，程序员养成的习惯只是一个好习惯，但好习惯的存在是有原因的。

【讨论】：

【解决方案4】：

我以前也见过这种做法，事实上，有一次我在一个项目中必须搜索一个常量文件，这导致我找到一个 XML 文件，该文件最终会给出我正在寻找的属性名称。然后我也必须查看属性文件，因为值是我真正想要的。

我认为这是 Jeff 和 Joel 在 the last podcasts 上讨论的一个例子，开发人员在盲目地遵循他们听说过的做法（在这种情况下，永远不要在您的代码）而不考虑考虑到手头的问题是否真的合适。

【讨论】：

是的，如果一个常量只被引用一次，那么它的值是可疑的。如果常量名称替换了幻数，则单独引用常量 can 会很好，但在这种情况下，即使这样也不适用。但是，如果键名出现在代码中，那么我会坚持使用常量。
在这种情况下呢？为什么属性键名会改变？这是更可能改变的价值。
如果应用程序使用这些间接，那么必须存在函数来进行查找。编写一个 4 行 main 函数来调用这些函数，而不是自己搜索文件。好的程序员都是懒惰的。
等等，所以你认为编写代码而不是简单地在 IDE 中使用“搜索”功能是一种很好的利用时间的方法吗？我正在编写这段代码来绕过一个非常迟钝的设计？谈论在霰弹枪伤口上贴创可贴......
您说您必须搜索三个文件，而不是一个。要么进行该搜索没有问题，并且您的第一个答案无效，要么这是一个问题，因此如果您必须进行两次以上的搜索，请为其编写脚本。

【解决方案5】：

因为自动完成在常量标识符上效果更好，但如果所有键值都是“com.foo.bar.whatever”，则不会收到任何反馈。

【讨论】：