Enums VS Classes VS Interfaces
我在这个网站上读了很多关于常量用法的文章。
问题：什么时候应该使用常量的枚举，而使用类或接口的枚举。
我看到了两个我想要解决的关键情况。
1。多个项目在应用程序中使用的全局常量。
例子：
- 常用日志记录字符串
- 容器引用，如中使用的数据库映射引用WebSphere EAR的
小精灵2。对象特定常量
例子：
- 员工对象的员工工资率
小精灵
从我读过的每一篇文章来看，这就是我认为我掌握的东西，以及我正在寻找的观点。
对于情况1：设计方法：使用最后一个类和静态导入。这里看到：接口常量的用途是什么？
对于情况2：设计方法：应用枚举将这些常量表示为对象。
需要记住的其他要点：
- 如果常量字符串属于类，并且只需要字符串值保留在使用它的类中
- 不要在情况1中使用接口。如上链接所述，作为恒定的接口反模式。.
小精灵
提前感谢您的想法和意见。
- 字符串已经是不可变的，所以几乎不需要将它们存储在枚举中。页面名称似乎不太静态，而且由于在运行时无法扩展枚举，所以最好使用字符串。数据库引用似乎或多或少是静态的，但我假定它们通常也由字符串表示。似乎没有直接的必要列举它们。确保使用枚举作为选项而不是作为需求来设计应用程序。
全局常量应该放在属性文件中，因为它允许每个应用程序单独配置它们，而不需要修改代码。对于特定于对象的常数，我对Enum与static final的一般经验法则通常倾向于有多少个元素以及这些元素之间的关系。如果他们之间有很大的关系，比如说在一个甲板上的Suits，那么我会去枚举。如果它是一个用户的默认年龄，那么这将成为最终年龄，因为没有任何目的使它成为一个枚举，因为它不需要在许多领域中被引用。这些只是我对每一种接近它的方式的一些想法。
- 这是关于数据库或配置文件的一个好观点。我应该更清楚这一点，阅读了很多关于这方面的文章。这将是影响应用程序逻辑的全局静态字符串的方法，但不会像日志记录中那样用于存储静态字符串。我仍然认为静态类导入会更好，你不认为吗？例如，记录通常使用的语句，如"enter method"或"exit method"，这些语句是为调试而添加的。
- @haju这些可能仍然在属性文件中。原因是记录器仍然必须构造日志语句，这样常量就不会有助于提高性能。属性文件还使您更容易更改为其他语言，如日语或C。
- 我认为注释的语言不会改变，除非代码被另一家公司LOL购买。我认为这样会有更多的事情需要担心LOL。对我来说，这样的属性文件，并通过一个属性管理器加载它们以将其持久化到其他类中。我更喜欢使用静态导入的类的简单性。本例中的所有首选项。
不同项目使用的全局常量：Enum。在一个类中，最好使用Enum而不是public static final成员。我想更干净更容易理解。
对象特定常量：public static final members in Class。因为，它们只在对象的范围内需要，所以不需要为此创建新的枚举。
读得不错
更新(修复断开的链接)：
- 充分利用Java 5：EnUM技巧
- 充分利用Java 5：EnUM示例
- 我有点不同意这一点。也许我没有清楚地表达我的意思。我同意其他的海报，我应该更多地考虑它。如果它是一个静态的全局常量，影响应用程序逻辑数据，它应该在数据库或配置文件中表示。但是，如果它是一个一次性使用的特定于对象的常量，我会像您所说的那样使用类中的静态最终成员。否则，我将使用枚举重构对象常量。
听起来，您为数字1和2列出的几乎所有内容都属于配置文件或数据库表。
您想在员工加薪或页面名称更改时重新编译代码吗？
除非有令人信服的原因，否则所有其他常量都应建模为枚举。通过这种方式，可以实现快速对象相等比较的好处，并避免与字符串常量相关的问题。
但是，这些枚举的范围是特定于应用程序的。如果枚举仅由类使用，则该类应为私有枚举。如果它由多个类共享，那么它应该在自己的类定义文件中。
- 是的，你是对的，就像Woot4Moo的评论。然而，有一种情况并非如此，那就是像我在上面的评论@woot4moo中所说的，常见的日志语句。
- 公共日志语句的真正用途是什么？我写了很多行代码，但没有找到通用日志语句的必要性。但我不知道你的情况，所以我尽量不去判断。我仍然认为这些都属于一个配置或属性文件，这样它们就可以在不需要编辑代码的情况下进行修改/国际化，并且通过利用适当的框架获得属性替换的好处。常量类通过强制系统中的每个类与常量类之间的非自然静态依赖关系来破坏OO代码