Java 5 中的静态字符串常量 VS 枚举+
我已经读过这个问题&答案： 在 Java 中实现常量的最佳方法是什么？< /a>
并得出一个决定，即枚举是实现一组常量的更好方法。 另外，我在 Sun 网站上阅读了如何将行为添加到枚举的示例（请参阅前面提到的帖子中的链接）。 因此，将带有 String 键的构造函数添加到枚举中以保存一堆 String 值是没有问题的。
这里的唯一问题是我们需要添加“.nameOfProperty”才能访问字符串值。 因此，在代码中的任何地方，我们不仅需要通过其名称（EnumName.MY_CONSTANT）来寻址常量值，而且还需要像这样（Enum.MY_CONSTANT.propertyName）。
我在这儿吗？你觉得怎么样？
I've read that question & answers:
What is the best way to implement constants in Java?
And came up with a decision that enum is better way to implement a set of constants.
Also, I've read an example on Sun web site how to add the behaviour to enum (see the link in the previously mentioned post).
So there's no problem in adding the constructor with a String key to the enum to hold a bunch of String values.
The single problem here is that we need to add ".nameOfProperty" to get access to the String value.
So everywhere in the code we need to address to the constant value not only by it's name (EnumName.MY_CONSTANT), but like that (Enum.MY_CONSTANT.propertyName).
Am I right here? What do you think of it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，命名可能看起来有点长。但没有人们想象的那么多...
因为枚举类已经给出了一些上下文（“这属于哪一组常量？”），实例名称通常比常量名称短（强类型已经与其他枚举中的类似命名实例区分开来）。
此外，您还可以使用静态导入来进一步减少长度。为了避免混淆，您不应该在任何地方使用它，但我认为与枚举强链接的代码可以很好地使用它。
在枚举的开关中，您不使用类名。 （在 Java 7 之前的字符串上甚至不可能使用开关。）
在枚举类本身中，您可以使用短名称。
由于枚举具有方法，因此许多大量使用常量的低级代码可以从业务代码迁移到枚举类本身（动态或静态方法）。正如我们所看到的，将代码迁移到枚举进一步减少了长名称的使用。
常量通常按组进行处理，例如用于测试与六个常量之一或其他四个常量等是否相等的
if。枚举配有EnumSets和contains方法（或类似的返回适当组的动态方法），允许您将组视为一个组（作为次要优点，请注意这两个实现分组的速度非常快 - O(1) - 并且占用内存很少！）。有了这些要点，我发现实际的代码要短得多！
Yes, the naming may seem a bit longer. But not as much as one could imagine...
Because the enum class already give some context ("What is the set of constants that this belong to?"), the instance name is usually shorter that the constant name (strong typing already discriminated from similar named instances in other enums).
Also, you can use static imports to further reduce the length. You shouldn't use it everywhere, to avoid confusions, but I feel that a code that is strongly linked to the enum can be fine with it.
In switches on the enum, you don't use the class name. (Switches are not even possible on Strings pre Java 7.)
In the enum class itself, you use the short names.
Because enums have methods, many low-level codes that would make heavy use of the constants could migrate from a business code to the enum class itself (either dynamic or static method). As we saw, migrating code to the enum reduces the long names uses even further.
Constants are often treated in groups, such as an
ifthat test for equality with one of six constants, or four others etc. Enums are equipped withEnumSetswith acontainsmethod (or similarly a dynamic method that returns the appropriate group), that allow you to treat a group as a group (as a secondary advantage, note that these two implementations of the grouping are extraordinarily fast - O(1) - and low on memory!).With all these points, I found out that the actual codes are much much shorter !
关于常量的问题 - 枚举应该表示所有相同类型的常量。如果您正在执行任意常量，那么这是错误的方法，原因在其他问题中都有描述。
如果您想要的只是字符串常量，那么就详细代码而言，您是对的。但是，您可以重写 toString() 方法，返回属性的名称。如果您只想将字符串连接到其他字符串，那么这将为您节省代码中的一些额外的冗长内容。
但是，您是否考虑过使用属性文件或其他国际化方法？通常，在定义字符串的 det 时，它是用于用户界面消息的，将它们提取到单独的文件中可能会为您节省大量未来的工作，并使翻译变得更加容易。
With regard to the question about constants - enums should represent constants that are all the same type. If you are doing arbitrary constants this is the wrong way to go, for reasons all described in that other question.
If all you want are String constants, with regard to verbose code you are right. However, you could override the toString() method return the name of the property. If all you want to do is concatenate the String to other Strings then this will save you some extra verbosity in your code.
However, have you considered using Properties files or some other means of internationalisation? Often when defining dets of Strings it is for user interface messages, and extracting these to a separate file might save you a lot of future work, and makes translation much easier.