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 nor unique within a system? Oy!

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.

"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

See: SingletonPattern, SingletonsAreEvil