最近，我遇到了很多依赖“属性文件”进行配置的Java代码。但是代码不是普通的旧字符串文字，而是使用常量（静态最终字符串）来检索属性值。
我发现这种额外的间接级别令人讨厌，因为我需要在 EITHER 方向执行 TWO 查找。如果我从配置文件中观察到的属性开始，我必须首先搜索属性名称以找到Java常量，然后再次搜索以在代码中查找对常量的引用。如果我从代码开始，我必须找到常量的实际值，然后才能确定配置文件中属性的值！
有什么意义？
我理解使用常量引用资源包中的键的价值，通常支持i18n。我指的是简单的，非面向用户的配置值。我能想到的唯一原因是为了让以后更改属性名称变得容易，但这个好处远远小于骚扰恕我直言，特别是考虑到全球搜索和替换的简易性。
答案 0 :(得分：11)
首先，在使用常量而不会出现编译错误时，不能错误键入键。
答案 1 :(得分：6)
如果一个值需要在没有重新编译的情况下进行更改，则不可避免地需要一些重定向，但是除非需要在多个位置引用密钥（本身可能表示关注点分离不当），否则执行另一个操作非常愚蠢。 / p>
关键字符串应该具有足够的描述性，以至于它们不能与其范围之外的其他人（通常是类）发生碰撞，并且将文字保持在单个类中是唯一的，既不复杂也不可能是如此严重，以至于值得在单个块中声明它们。因此（IMO）这种做法只是在没有理解规则原始意图的情况下盲目遵守规则的人。
如果你需要为他们引用一个替代指南以证明放松这个，我可以建议KISS。
答案 2 :(得分：5)
即使在使用常量进行简单全局搜索和替换（这不是新事物）的那一天，您也知道String仅适用于该属性文件。这很好，因为：
在很多情况下，这只是程序员进入的一个好习惯，但良好的习惯是有原因的。
答案 3 :(得分：0)
我之前也见过这种做法，事实上，当我在一个项目中，我必须搜索一个常量文件，这导致我得到一个XML文件，最终会给我一个我正在寻找的属性名称。然后我不得不查看属性文件，因为该值是我真正想要的。
我认为这是Jeff和Joel在the last podcasts上讨论的一个例子，开发人员盲目地跟随他们听过的做法（在这种情况下，练习永远不会有字符串）在你的代码中字面意义）而不考虑它是否真的适合于手头的事情。
答案 4 :(得分：0)
因为自动完成功能在常量标识符上效果更好，但如果所有键值都是“com.foo.bar.whatever”，则无法获得反馈。