Using enums to implement utility classes and singletons

Pete开发者_如何学JAVAr Lawrey writes about Two Uses of Enums that most people forget on his blog.

First of all, I hadn't forgotten - I hadn't even realised :)

These approaches are nice and concise - are there any benefits other than conciseness compared with the more traditional ways of achieving the same thing, such as using final classes with private constructors for utility classes?

Also, are there any issues (apart from confusing programmers who aren't expecting it)?

It would seem more intuitive to me to use enums for real enumerations.

I don't really agree with the first use of an enum from that post. If you want an uninstantiable utility class, just give it a private constructor. It's that simple, and the enum provides no added benefit in that situation that I see.

The use of enums for singletons in utility classes is great, but I would generally try to keep the fact that an enum is being used an internal implementation detail. See, for example, Guava's Predicates class which uses an enum to enforce a single instance of certain Predicates like alwaysTrue(). It does not expose the enum to users though.

As far as other benefits: yes, there are other benefits such as built-in serializability and absolutely enforcing a single instance of an enum constant per classloader, even when deserializing.

My first instinct in both cases was that they were nasty hacks.

In the case of the singleton however, I think that you could reasonably argue that, in a language where enum constants are first class objects, there is conceptually no difference between a singleton and an enum with only one value. I'm still not sure I'd actually use the technique though, especially since the singleton pattern is pretty unpopular for other reasons.

Using an enum for a utility class is harder to defend. There is no conceptual reason for a set of utility methods to be expressed as an enum (arguably there's no reason for them to be expressed as a class, but that's a whole other debate). It seems the only justification for implementing utility methods this way is to save a little bit of typing by ignoring established conventions.

In addition to the obfuscation concern of using Enums for things that are not enumerations, using Enums for singletons has the same downfalls as other ways of hard-coding singleton scope, basically it impedes testing and makes inheritance or other extension difficult. It's a much better idea to let singleton scope be controlled by a factory like in Spring.

I do not like this approach. Enums should be kept simple enumerations really. They should contain conversional logic at most. Using the enum as a singleton or interface looks like an obfuscated code to me.