your quote says that one should use enums anytime one needs “a fixed set of constants”.

Well, singleton is a pretty fixed set isn’t it? Actually, in Set theory, the term “singleton” reffers to a set with one member.

From http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

“So when should you use enums? Any time you need a fixed set of constants. That includes natural enumerated types (like the planets, days of the week, and suits in a card deck) as well as other sets where you know all possible values at compile time, such as choices on a menu, rounding modes, command line flags, and the like. It is not necessary that the set of constants in an enum type stay fixed for all time. The feature was specifically designed to allow for binary compatible evolution of enum types. ”

That’s why enums doesn’t fit for singleton…

I’m not against DI, but use it because it makes sense to do so – ie you plan to swap out in testing and use different implementations of your interfaces. I’m curious what % of people are doing this? I test my services and daos but I’m not testing mock ones.. I want to test the real thing.

For the poster commenting about static methods instead, there is a big difference: If I uses singletons I can implement an Interface and thus provide a different implementation of my singleton if need be. You can’t do that with a class with static methods.

I think it is safe if you’re not using multiple calssloaders.

As far as comments and ideas:

1. I think it would be better (from design perspective) to have a separate factory (which would serve one purpose) and four separate enum singletons (also one purpose each). Of course all four objects should be polymorphic, in other case I don’t see any point in having a factory at all.

2. Your enum doesn’t use constructor parameters, so you can leave out the ‘()’ near instances, like KEYVALUEPAIRS {…

3. Idea from 2. – you can create needed objects in enum constructor like:

public enum ZFactory {
    ...
    KEYVALUEPAIRS(new KeyValuePairs()),
    JTABBEDPANE(new JTabbedPane());

    ZFactory(Object obj) {
        this.obj = obj;
    }

    private Object obj;

    public Object get() {
        return obj;
    }
}

And of course it’s better to refactor it to 1. with separate factory.

For a Swing app I needed single-instances of certain classes at the application level.

I use Guice for other apps but guice.jar is 544k; I used pico also but pico.jar is 249k so I decided on an enum-based class to implement this Singleton/Cache function at the application level.

Enclosed below is the class I am using now; it works but I do not know how safe it is and whether it is useful/safe in an environment such as a servlet for application-level objects: any comments, ideas; thanks for the post:

public enum ZFactory {

    KEYVALUEPAIRS() {
        public Object get() {
            if (kvp == null) kvp =  new KeyValuePairs();
            return kvp;
        }
    },
    ENCODERDECODER() {
        public Object get() {
            if (ed == null)   ed =  new EncoderDecoder();
            return ed;
        }
    },
    BARCODEIMAGE() {
        public Object get() {
            if (bci == null) bci =  new BarCodeImage();
            return bci;
        }
    },
    JTABBEDPANE() {
        public Object get() {
            if (tp == null)   tp =  new JTabbedPane();
            return tp;
        }
    };

    protected KeyValuePairs kvp = null;
    protected EncoderDecoder ed = null;
    protected BarCodeImage  bci = null;
    protected JTabbedPane    tp = null;

    public abstract Object get();
}

Actually, ahem, I also came up with the idea of using a single enum constant for the Singleton implementation in Java 5/6 around May 2007 during the writing of my Master Thesis, which has been publicly available on the net since January 2008. Well before Bloch published the second version of his excellent book (which I have not read yet!) – though he most certainly thought of it looong before, I know! :)

So, in my megalomania I dubbed this as the Singleton-as-Single-Constant idiom… :)

See for yourself at http://www.rode.dk/thesis

Regards – Gunni

(flaming commence…)

I agree about the source code confusion, but we have comments for that.

And about “this kind of singleton is no different” is not true, it’s different. For classic Singleton to be serialiazable you have to implement Serializable and declare all instance fields transient and provide a readResolve method. In other case after serialization deserialization you will get a new instance.

With enum approach you don’t have to think about it.

But as what others mentioned to use an enum represent something which is not an enum will obfuscate the code. Cause un-necessary confusion for the source code reader.

Another issue is this kind of singleton is no different as using class with static members.

One reason why we use singleton is to make the class lazy instantiate to break possible recursive initialization of classes because of cross dependencies. Singleton objects should be created only when it’s used rather than when the class is loaded.