Skip to the end for a quick summary
I have worked with a lot of code containing a lot of Singletons, many caused by my own hand, and they have one thing in common. They all sucked. Sorry let me quantify that horrendous statement; the fact that the object(s) were Singletons made working with the code in an environment other than production nigh on impossible. The underlying code was sound. What was using the
Singleton.getInstance() accessor rather than forcing code to pass a reference to the object which at one point so happens to be a singleton. Imagine these scenarios:
public class MyClass {
private final Singleton sing = Singleton.getInstance();
}
public class MyClass {
private final Singleton sing;
public MyClass(Singleton sing) {
this.sing = sing;
}
}
Wow so it's the same overall effect (an instance of Singleton makes its way in MyClass) but the second one is just plain better. Get your Singleton to implement an interface & then you've succeeded in a decent level of separation (which is what my group did with the last Singleton). But there was one thing that I was confused about (but did not know) & it's very similar to people who hate Javascript. A singleton (a single instance of an object) is a very good thing; a Singleton (a globally held reference to a single instance of an object) is not & never will be. However a program needs a context to run from (which is what the Singleton was being used for).
Just think about something like Struts (1.x); there's only normally one instance of an ActionServlet per application. A context if you will. This is where Miško's article has really driven this point home. A single instance of an object is no bad thing; in fact it's normally quite a desirable thing. What hurts you is the Singleton anti-pattern. It becomes gospel; the alpha and the omega and trust me you do not want to program yourself into this cul-de-sac.
Anyway to summarise Singleton bad; single object instance good.
