When is Singleton appropriate?
I've seen many explanations why is Singleton is evil. But is there really no such a case when Singleton is the only beautiful solution?
marked as duplicate by Mark Trapp Sep 12 '11 at 18:22
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
want to hear a common myth?
"Singletons are a way to limit the number of instances of a certain class to one."
If that's how most people used singletons, the only thing I would have to say is "Well, why not just create ONE and stop there?"
But that's not the issue. The real problem here is that people use singletons to introduce global state to object-oriented programs, or just to shove in another (anti) pattern.
If you want to have a single instance of a certain class, that's perfectly fine. But why make it accessible from anywhere in your code? That's called opacity, my friend, and that's what you should watch out of.
Instead of using singletons, read up some more on dependency-injection and chain of construction (factories, etc). Depend on services (objects) you need. Don't try finding them by yourself (from the object's point of view) or access them globally.
I have never seen nor heard of any case which justifies limiting an object to just one instance.
Even in hardware, you can never guarantee what can happen in the next few years- for example, in 1990 or 1995 you might have said that a graphics driver might reasonably use one. But then, you get SLi invented. Whoops. The same occurred with printers. You can't justify the use of a Singleton just because it doesn't make sense - it has to be actively system-destroying. Such instances do not exist.
When trying to shoehorn an app into some tiny, very memory and/or performance constrained, micro-controller. One can even turn a singleton into a global var/struct/array, which the compiler can optimize into far fewer bytes of machine code.
For super high volume consumer items, beauty is often saving a few pennies or cubic mm. Generality (portability, reusability, maintainability, etc.) has costs. No need to pay if you aren't going to use the benefits that go with those costs.
It depends on what you call a Singleton.
edit> The link from Problematic in the question's comments might help to understand what I mean here : When is Singleton appropriate?
If the construction and destruction of the unique instance don't have to be explicit, then it's EVIL.
If not, then there are some specific cases where it's clearly a good solution. The main one I'm using is when the unique instance represent the state of a "system" that is "global", like a hardware api.
That said, if you're in this case, you could replace your singleton by free functions... if your language allows it. If not then I guess it's a reasonable choice.
Just keep in mind : global access means that if there is a problem with your singleton object, you might have propagated it everywhere it is used. That's why if you can remove the global accessibility, it would be far better.
In a more general way, when you start thinking that a singleton might be necessary, think twice or more. It can always be replaced. There is just a tradeof that might be (or not) too expensive for you. Now it don't mean you don't have to use it at all ever in your life. It might be worth sometimes. But it's rare. So, as a rule of thumb, just don't use it. Rules are made to be understood then to be broken when you understand when it's a good idea.