Quote:Original post by Oluseyi
The problem with the singleton is that it solves an extremely niche case, is far too easy to implement, is entirely too popular given its limited applicability, gives beginners a false sense of sophistication, and is the least useful of the available design patterns. I wish beginners were learning MVC or adapter or observer like this.

Personally, I don't even consider the singleton to be a design pattern - there's a huge difference between "I only need one" and "There can be only one," and the fact that it conflates the two makes it suspect to me.

This may be true, but I believe that the singleton lies at the top of the design pattern teaching methods. It is only a vehicle to teaching exactly what design patterns are, which runs counter to your claim that it is not, in fact, a design pattern.

I have to assert that Singletons are a design pattern, because they reemerge time and again, thus sufficing its definition as a design pattern. I don't deny that the singleton is overused or misused, however it remains an extremely useful tool in explaining design patters and in designing other pattens.

In essence, if you are to explain design patterns at all, you must first explain the Singleton.

Quote:Original post by ibebrett
is it me or has there been a ridiculous amount of threads about singleton threads lately?

I agree with Oluyesi, I think beginners like to use Singletons because it makes their code more fancy or something, but it probably has more to do with overdesign thing. As coders, i think we have an innate urge to organize our programs, and make the "perfect" and "organized" framework, but we sometimes forget the program is going to start somewhere, and you'll have your chance to create whatever object you wanted to be a singleton there.

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?

Quote:Original post by ibebrett
is it me or has there been a ridiculous amount of threads about singleton threads lately?

I think there's always a ridiculous amount of threads about singletons...
I think someone made a list in their journal once - it was a pretty long list.

Perhaps there should be a SIG on it?

Quote:Original post by Oluseyi

Quote:Original post by argonaut
I have to assert that Singletons are a design pattern, because they reemerge time and again, thus sufficing its definition as a design pattern.

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.

Quote:In essence, if you are to explain design patterns at all, you must first explain the Singleton.

Utter rubbish.

I am not denying that Singletons get overused or misused, but they are definitely an emergent pattern. However, I am in software development and we find that sometimes (about once a year, or so) that Singletons do come into use.

My main point was that this is part of the learning process, so don't call the guy a "noob" for asking about singletons. If someone is new, let them learn when a Singleton comes in. It's part of the learning process ... advice is fine, but calling them a "noob" [sic] is not.

Quote:Original post by Oluseyi

Quote:Original post by argonaut
I have to assert that Singletons are a design pattern, because they reemerge time and again, thus sufficing its definition as a design pattern.

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.

To address this idea of Singletons as an emergent idea, this is exactly what the "static" keyword introduces in C++. "static" as a keyword was introduced somewhere about 1986?

Though I agree with argonaut, I think both the popularity and loathing of the singleton pattern can be explained by poor education and/or understanding about propper object interactions. The singleton pattern simply allows people to quickly call some code or refer to an object globally in an OO environment, without thinking about how it should actually fit into the OO model.

For example, it looks much easier at first to call GameSingleton.GetInstance().DrawSomeStuff() than to actually figure out how the drawing logic could be elegantly expressed in a more practical model. The popularity of this approach might seem warranted, since naively put

1) We're working with objects, so it's propper OOM
2) We're using the singleton 'pattern', so it's elegant OOM

Upon closer inspection it's obvious that the singleton applied in this (typical) way just abuses the OO facilities of a language to call some code globally and it has little to do with OOM at all. In my experience though, these subtleties are typically neglected in education (both formal and informal) and the focus lies on droning patterns into students and demonstrating them pretty much exclusively in textbook examples.


Yes, I'm sure this discussion has been beaten to death, but I thought it might be more useful than to simply re-re-post the "singletons are bad" dogma.