In a comment a while ago, David wanted to know why are Singletons the root of all evil. Well, that’s just because they are!
Ok, it is not that easy. Nor that black-and-white, either. Let’s see if I can articulate some of the reasons why Singletons are bad for you and for your code.
From all the varieties of pattern abuse out there, singletonitis is the most irritating one because of two simple reasons:
- Singleton is one of the patterns with the worst side effects.
- Singleton abuse is one of the most widespread varieties of pattern abuse.
In 99% of Singleton occurrences, the Singleton pattern was unnecessarily introduced with one of the following excuses:
- Some object needs to access a resource that isn’t available in that abstraction layer. The right solution to this problem is to redesign. Solving bad design by throwing a pattern at it just makes things worse.
- As a glorified global variable. Global variables can be avoided most of the time, and they should be avoided wherever possible. See previous point on solving bad design by layering patterns on top.
- Premature optimization (”we shouldn’t instantiate this more than once, or it will bring down performance; let’s singletonize it!”). Thousands of wise words have been written on the evils of premature optimization, so I won’t go into that here.
So it all boils down to the following: in most cases, programmers introduce Singletons either as a misguided attempt to improve a bad design, or as a means for premature optimization.
Singletons not only have the noxious effect of obscuring how objects collaborate, but they also hamper dependency injection, which in turn makes testing and refactoring extremely difficult. Thus, Singletons lead you into a spiral of unmaintainability. To think that they were unnecessary in the first place!
3 comments ↓
Ana,
I love when you come back techie
I think this article can bring a hell lot of conversation about it; some technical, but some philosophical as well.
In my opinion, Singleton is not the root of evil, that is an exemplification of the misusage of any technology after all.
Singleton can be a great tool to avoid having multiple copies of an object that it must be unique in the whole application.
For example, in the last application I wrote, we had to create a Cache Manager. This class could not be layered on top, and I needed a “singleton” access to the Cache from all objects. They should not care were a single instance of the Cache exists or not, they just want to use it, but it should be unique.
I agree that something that usually falls into the “dark side of bad habits” should be advertised as “evil” (specially for children!), but as you said… not everything is white or black
Cheers!!
Fer
Fer,
If your objects wanted to use a global cache, why not have the cache be an argument to the instantiations of all those objects? Is it because someone could still choose to instantiate another version of the cache and pass it to one of the objects? Why are the objects so dependent on having a single version of the cache, is there some special interaction where one object writes and another one reads from the cache? Why couldn’t the Cache Manager be layered on top?
I was not convinced in the need for singletons in that instance.
Fer, I have to agree with Mario here: I see no reasons in your example why the cache manager had to be implemented as a singleton. An instance and dependency injection probably would have sufficed. Instead, you constrained yourself to the use of a singleton, probably unnecessarily.
Leave a Comment