I want to start this article by first explaining that by simply dismissing an idea in software, you are being ignorant – and your evolution as a programmer will be severely stunted – so this is not a flame against using the Singleton pattern – it is a series of important points you should take into consideration before doing so.
OOP’s answer to ‘globally accessible’
The singleton ‘design‘ pattern – is it really a design pattern? Probably not. For me, a design pattern is usually defined by a slightly higher level of abstraction than ‘a class that can only be instantiated once’, and it’s UML diagram should probably be a little deeper than just one class node. Whatever the case, this is not what I’d like to argue, because the fact of the matter is that it is a technique that exists, and it is a technique that is being widely used.
I have a general dislike for Singletons though, but it is not without reason. What bothers me about the Singleton pattern is the likelihood it will crop up in projects with no real justification. It’s becoming a parasite, an overused technique that can often cause more problems than it solves. It is very often the lazy programmers’ excuse to avoid designing something a little better, or even designing anything at all. It is becoming the object oriented programmers’ ‘global variable’.
The difference between globally accessible, and the ability to be instantiated only once
I shouldn’t need to elaborate on that title, but unfortunately I probably do – so bear with me.
A Singleton is defined as a class that can be instantiated only once. If somehow this doesn’t hold up – and it can be constructed more than once, it is not a Singleton.
Thanks to some platforms, we can use a private constructor to achieve this requirement. What we shouldn’t be thankful for though, is that developers very often (in these platforms) use no protection against allowing their, more often than not, public static new instance method from being used anywhere in the entire code base. I needn’t explain how this violates good OOP principles, especially when it comes to ‘strive for loose coupling‘.
The moment you allow something to be globally accessible, directly, without hiding its implementation behind some clean interface – you are inviting developers to tangle your code into an unusable mess – and the sad truth is that many singleton implementations are done just like this.
The singleton pattern does not endorse you to make something globally visible; the singleton pattern endorses only one thing, and that is, your class can be instantiated only once.
Developers will sometimes lazily decide that they want some particular resource to be visible anywhere in their code base – with no thought of architecture, consequence or just general good practice. They will then hide their original intent by creating a ‘singleton’. The reality is, they are not worried if more than one instance of the class is instantiated and are really just in denial of their bad practices – hiding behind the singleton as though it justifies such code. This pattern is something I like to call a Lazyton.
You are not lazy. Don’t make Lazytons.
When should I use a Singleton?
Surprisingly, this one is quite obvious. Incline yourself to read the manual, if you do not wish to though – allow me..
Use a singleton when, and only when, a class need only be instantiated once - and if it was instantiated more than once – it would wreak devastation and cause unspeakable problems for your system.
If I don’t want to use Lazyton’s, but need publicly visible resources, what can I do?
Now, I like this question. It provokes a little thought.
Dependency injection. There’s the answer, and it’s nothing new. Infact its one of the OOP paradigm’s ways to avoid ‘initializations’ problems. The constructor, anybody heard of it?
If you’re using Java and are already familiar with dependency injection, check out GUICE. If not, read up on it. You can read this article I wrote – it’s very simple, but it gets the point across.
Dependency injection does exactly what it says on the tin, it injects dependencies into your classes via the constructor – so upon construction they require no initialization and are ready to go. If your class needs access to the IDataAccessLayer – no problem, and no need for the entire code base to see it.
If by some reason you’re against it, or your project is dying a death and you in all honesty don’t have a lot of time to invest in such a practice – at least generalize your global access usage to some resource manager. Rather than having ten resources with ten different public static accessors – create one global access point with a clean interface that will allow you to manage, retrieve and update resources at your will. That way, if something changes in the future regarding these resources, you are managing the change in one place, not ten. It will also allow you to adapt the single accessor in the future if you’d like to refactor, and believe me, you probably will.
So next time you think it’s cool to make a Singleton. Ask yourself why. Ask yourself if it is really warranted, or if you are just being lazy.
And yes, I use Singletons sometimes.
If you liked this article, you might also like the following:
The True Singleton in ActionScript 3.0
Don’t use design patterns just to use design patterns
