Static String constants VS enum in Java 5+

Question

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?

Solution 1

Yes, the naming may seem a bit longer. But not as much as one could imagine...

1. 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).

2. 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.

3. In switches on the enum, you don't use the class name. (Switches are not even possible on Strings pre Java 7.)

4. In the enum class itself, you use the short names.

5. 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.

6. Constants are often treated in groups, such as an if that test for equality with one of six constants, or four others etc. Enums are equipped with EnumSets with a contains method (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 !

Solution 2

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.

Comments

[Michael Aaron Safyan]

Could you clarify the question? Are you using a member variable instead of using an accessor function?

[EugeneP]

Whatever. Say, accessor function. That additionally gives () The question was about verbosity, as KLE and N. Fortescue wrote. But as was told, I can override toString (interesting decision), and most importantly, I can see that using enum can be a good practice here.

[CppDude]

@EugeneP For me and many others, toString() is supposed to be a debug String (good when debugging, for technical logs and the like). The problem of using it in the normal course of the application is that some day, somebody will override it to show more info in debug, thinking it will have no impact on the application's behavior.

[EugeneP]

hm. interesting. The problem here is that this structure (enum) will be used to hold Strings and nothing more. So generally I can understand that an Object should use it only for debug purposes, but that is not the case here, do not you think? In my opinion our enum here is kind of a String object ! So, when we talk about a String object, we do not use it's method toString for debugging purposes! Am I correct?

[Jasper Floor]

Java toString is meant to provide a "concise but informative representation that is easy for a person to read." Though it is used by some for debug code this is breaking the contract and should not be considered correct. Using it to create a printable version is the correct usage. If you use toString in the correct way you should not worry about someone coming in some day and doing something wrong. That can always happen and then you may as well not do anything.

[CppDude]

@Jasper Precisely, the description is for a person to read (like in a log), and might or might be be appropriate in a precise screen. In my experience, an object often end up been used in several screens, with varying representations. Also, most objects have several fields that are shown in distinct fields with appropriate formatting, so building a toString() is not useful for display to the end user. So I believe the description you give correspond to my idea of a debug String (seen in debug or logs, and that won't break the application). @EugeneP However, enums might be a special case!

[Jasper Floor]

@KLE A debug string is not a concise, informative representation as it will contain debug data. Using it the way you suggest is not implied by the contract. Therefore anyone using it need not expect that behavior.

[CppDude]

On toString() overriding, I believe any developer can use it anytime to show more info in debug (also for technical logs). If your actual application behavior depend on it, your code will break, it lacks robustness.

[CppDude]

On the use of Properties for end-user messages, definitely yes! Anyway, instances names cannot use special characters, must be all capital letters separated by '_' (like all constants) ... so they are not usable for end-user messages.

[Jasper Floor]

Again, using toString for debug is code is the incorrect usage. Follow the API contract and your code is more robust. Break the contract and your code is less robust.

[EugeneP]

enums should represent constants that are all the same type - useful remark.