Understanding Singleton Pattern

Started by
25 comments, last by valentin-galea 15 years, 11 months ago
Quote:Original post by Oluseyi
The need for a singleton does not emerge time and time again. The desire to use one does, which is not the same thing, and which does not qualify the singleton as a design pattern. In the last five years, I think I have only heard one case where a singleton was legitimately required.

I've had to use them quite often recently when having to write "integration layers" on top of legacy 3rd party libraries. My requirements tell me to turn the library into "some kind of modern class library", but the legacy code tells me that it will crash if I instantiate more that one of certain objects that it provides.

I am legitimately justified in applying the Singleton or Monostate pattern here? Or am I just imagining the constant emergence of this need in my work?

Yes it often gets used unnecessarily used, but it also has legitimate uses, which (depending on the area that you're working in) can come up more often that you would have us believe.
Advertisement
And for good measure:

Quote:Original post by Hodgman

...

Yes it often gets used unnecessarily used, but it also has legitimate uses, which (depending on the area that you're working in) can come up more often that you would have us believe.


I wholeheartedly agree. Elegant OOM design is one thing, but it doesn't always go well with getting stuff to work in a reasonable amount of time and without introducing mindboggling complexities. It's such a thin line between complex OOM and YAGNI. Pragmatism FTW! [smile]
Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!
Quote:Original post by remigius
And for good measure:

Quote:Original post by Hodgman

...

Yes it often gets used unnecessarily used, but it also has legitimate uses, which (depending on the area that you're working in) can come up more often that you would have us believe.


I wholeheartedly agree. Elegant OOM design is one thing, but it doesn't always go well with getting stuff to work in a reasonable amount of time and without introducing mindboggling complexities. It's such a thin line between complex OOM and YAGNI. Pragmatism FTW! [smile]


Nice! I could not have (and, in fact did not) put the entire argument into a tighter scope. I salute you, sir!

~Argonaut________________________________Why "~Argonaut"? It's all just a mathematical expression denoting a close approximation of "Argonaut", which is irrational and can't be precisely defined.
Quote:Original post by Hodgman
I am legitimately justified in applying the Singleton or Monostate pattern here? Or am I just imagining the constant emergence of this need in my work?
The checklist in this article on Singletons suggests that a singleton would be justified if the following conditions are true:
  1. Is there a need for the considered functionality to be grouped in an object?
  2. Is there a need for the considered functionality to be grouped in a class?
  3. Is there a technical reason for which the considered functionality does not allow multiple instances of the class?
  4. Is there a need for the unique instance to be globally accessible?

Have a read of the article for a more in-depth look at each of those items and the reasoning behind it. Your description doesn't go into a great deal of detail, but the requirement for global access may not be neccesary in your example.

Quote:Original post by argonaut
In essence, if you are to explain design patterns at all, you must first explain the Singleton.
There's absolutely no reason you couldn't teach the idea of design patterns without mentioning Singletons at all, nor are singletons neccesarily a best first place to start if you're teaching specific design patterns rather than just introducing the concept. They may well be a valid option as a first pattern to teach or relatively simple example of the idea of a design pattern (I'd personally avoid them, as I consider them to be very overused and often poorly understood, and therefore may be better left till the programmer is a bit more experienced), but "may first explain the Singleton" is very different from "must first explain the Singleton" as you suggested.

Quote:Agreed, but is the pattern bad or the teaching bad? I use singletons once in awhile, does that make me evil or the reason I use them evil?
The abuse of the Singleton pattern is of course due to misunderstanding and misapplication, which may be a result of poor education on the subject. The pattern itself is certainly valid in some (I would suggest rare) cases, and generally when a capable programmer refers to a construct as "evil" they do understand that and are rather indicating that due to common overuse and/or misunderstanding people (particularly those who may be knew to the construct or pattern in question) should take additional care that their usage is indeed appropriate.

We know the pattern is appropriate and useful sometimes, but are suggesting that those cases are rarer than a lot of people think and that more thought should be put into possible alternatives before jumping in with the pattern. Learning about Singletons is not a requirement for understanding the underlying concept of design patterns, nor is knowledge of it prerequisit for learning most other design patterns, so it need not neccesarily be the first pattern someone is taught.

[Edited by - jbadams on May 14, 2008 3:40:06 AM]

- Jason Astle-Adams

Quote:Original post by jbadams
... when a capable programmer refers to a construct as "evil" they do understand that and are rather indicating that due to common overuse and/or misunderstanding people (particularly those who may be knew to the construct or pattern in question) should take additional care that their usage is indeed appropriate.

We know the pattern is appropriate and useful sometimes, but are suggesting that those cases are rarer than a lot of people think and that more thought should be put into possible alternatives before jumping in with the pattern. Learning about Singletons is not a requirement for understanding the underlying concept of design patterns, nor is knowledge of it prerequisit for learning most other design patterns, so it need not neccesarily be the first pattern someone is taught.


I don't think anyone has taken an issue with branding it as "evil", but rather with only doing the branding and very little explaining. Of course you'll get a discussion when such blanket statements are made (and n00bness is derived) without further clarification or justification.

Whether or not singletons are the mandatory first pattern is up for debate, but I think the discussion in this thread alone and misunderstanding in general makes it clear that singletons should be taught in depth. Specifically, it would make a perfect case to show how easy it is to misunderstand and/or abuse patterns and that patterns are by no means the holy grail of OOM by themselves.
Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!
Quote:
In essence, if you are to explain design patterns at all, you must first explain the Singleton.


WTF?...
The most valuable information you will find about Singletons is in the book "Modern C++ Design" by Andrei Alexandrescu.

Find more info here. There is also a lib he created for the book and later expanded: Loki - you will find there an all-purpose Singleton class.

This topic is closed to new replies.

Advertisement