Fixing the Singleton
When you ask people who know almost, but not completely nothing about patterns, about software design patterns, they probably bring up the singleton pattern. It’s extremely easy: Just make sure you have one single instance of a class.
If you ask more experienced developers about the singleton, they will probably tell you its bad and should be avoided.
What is so bad about the singleton that it fell from the heavon of patterns into the hell of anti patterns?
If you check the description of the singleton pattern in the Gang of Four book it talks about two characteristics of the singleton:
- There can be only a single instance
- There is a central access point to that instance
And there really is nothing wrong about the first point. Sometimes you really can’t have more then one instance, but even if multiple instances don’t hurt, if they don’t give you any benefit (i.e. if they are stateless) you might as well reuse a single instance.
The problem is really with the central access point. This makes the singleton look and behave like a global variable. And how should we obtain our dependencies? Correct through Dependency injection.
So the next time you think: “Looks like a singleton to me”. Go ahead, create a singleton. But also create an interface which gets implemented by the singleton and make it very clear that nobody may use this singleton except via its interface and dependency injection through constructor.
HI Jens,
what exactly do you mean with your last paragraph? “via its interface” – I cannot see what you mean there.
Hi Andreas,
just as most other classes a Singleton should implement an interface. And clients using the singleton should not depend on the singleton itself, but on the interface.
So you mean injecting the instance? – Then you have the classic Spring/EJB/etc idea. Define a “Bean” and inject it. Then the Bean is the singleton, right?
Yes this is basically correct.
Actually I personally distinguish between the pattern ‘Singleton’, i.e. a class that can only create a single instance, and the usage of the class, which shouldn’t care if it is a singleton and might use classes which aren’t a singleton as if they are one.
Hm – i don’t see why wee need an interface here? Of course one should implement against interfaces, but personally I prefer having interfaces if I need them, i.e. if I have more then one interpretation of a type. If I have a class with typical functionality, I don’t need an interface for a better design. I would use “introduce interface” refactoring right at the time I have a second class doing well unter the same type. I don’t like those projects where you have all those interfaces around without any reason for them. These interfaces are mostly created because in early days some teacher told us to always use interfaces
You are correct. The interface (in the java sense) isn’t strictly necessary. In the generic sense of a contract which is independent of the implementation is necessary though.
I’m thinking that when you are referencing the implementation directly it is to tempting to access the instance directly instead of through dependency injection.
But I might be wrong about that.
Thanks for this great post! I’ve linked it in a new post about this topic! http://javapeanuts.blogspot.com/2012/02/singleton-testing-and-dependency.html
[...] http://blog.schauderhaft.de/2012/01/22/fixing-the-singleton/ Share this:TwitterFacebookLike this:LikeBe the first to like this post. This entry was posted on Monday, February 20th, 2012 at 5:20 pm and posted in java. You can follow any responses to this entry through the RSS 2.0 feed. « The 7 levels of continuous integration [...]