Singletons Are Good

Singletons are good when they are used wisely. One must know the environment in which they are being used.

Singletons are a poor choice in a clustered environment. One must be careful to update all the Singletons on all the machines in the clustered domain. This is cumbersome and should be avoided. Stateless beans are a better choice for this environment.

Singletons are the only way to resolve certain system resource issues such as doling out hardware-based facilities.

Singletons are at least unnecessary.

Everything that can be done with a singleton can be done with a class variable or method. And if something has to be unique, it has to belong to the class and not to the objects.

Therefore, good or bad, singletons are conceptually wrong.

Class variable or method is just an implementation of singleton.

Or, a Singleton is just a bunch of class variables and methods. -- DorKleiman

"Singletons are at least unnecessary."

Completely untrue. Singletons describe unique resources of a system. The simplest and most obvious is stdin/stdout. How about your PC's speaker? Are we going to claim that these are not resources or that they are not unique within a system? Oy!

Would you want every third party library you import to be hooked to stdin/stdout?

No. However, if a library is going to use stdin/stdout, it has to conform to the underlying system's adjudication of those resources.

Applications should only care that there is some stream that they can output audio to. Why can't you have music go to one output and game sound go to some other output, or route audio output from some program to the game input (voice changer, music to play to people in game, etc) without terrible kernel/system hacks?

That's great, but in real, existing systems there aren't provisions for that. We are stuck with the hardware/software platforms currently being manufactured, and those systems have many resources which are, in fact, singletons.

Singletons don't even describe uniqueness because the namespace of a singleton is not global, for example in Java you can create another instance of a singleton by loading it in another classloader. Or you can just start the application twice.

Thusly the need for a system-level singleton resource that is requested through an OS hook.

The stdin/stdout example is, in essence, a fundamental problem with how many people understand Singleton. stdin and stdout are unique, certainly. It also makes sense to have them globally accessible. But they're instances, not classes, so Singleton does not apply since Singleton ensures "a class only has one instance" [GoF]. stdin and stdout are globals, nothing more. And as for other system resources (hardware and the like), it shouldn't be up to client code to determine how many of each resource are present, or to use a non-parameterized method of obtaining them (such as a global function). Why not pass the object an instance of a SystemResourceManager? class? IsSingletonLaziness??

In the EmbeddedSystems world, there are all kinds of unique pieces of hardware that need to be identified by using a Singleton. This is how one avoids hardware control conflict. Examples abound.

Let's try to be a little more realistic here, eh?

[A PC may have zero, one, or many sound output channels. Sound may also need to be sent over a network protocol for remotely displayed applications. The hardware may support a limited number of simultaneous output channels, or software may supply arbitrarily many channels to be mixed down to the hardware output. Historically, many programs have assumed that there will only be one monitor - an assumption that causes poor UI behavior now that desktop PCs can commonly support multiple monitors.]

Singletons are unnecessary, as is every other design pattern, but they can be helpful. For example, my current code often requires a single instance of an class, but a future version may require multiple instances. In the latter case, it's easy to refactor the singleton to support multiple instances. In other words, singletons are easy to get rid off and help me avoid PrematureGeneralization.

Standard output is a global variable, not a singleton. Standard error is another instance of the same class, so clearly it's not a singleton.

"Singleton's are self-documenting". (ok - don't start your backswing to tee-off yet)

One thing I do appreciate about Singletons, is that the API has been widely read (GoF et al.). Therefore, if I see a class with no public constructors and a getInstance() method, it is obvious what is going on. Having a immediately recognizable API is part of the point of patterns in general - irrespective if they are used in the correct context. I much rather have to debug someones code where at minimum the APIs used are common rather than having to hunt down globals where it isn't immediately obvious that they are global.

-DavidVTHokie

So you are saying you see Asd.getInstance() and its Good because it can tell you that Asd is a singleton class? well I will tell you something better, let's simply name those classes STAsd because if you see the ST you know that its a singleton class

See: SingletonPattern, SingletonsAreEvil