I started out writing this post as a series of comments on StackOverflow but I decided there just wasn’t enough room to discuss this.
The original question is titled “What is so bad about Singletons?” and can be found at StackOverflow here. The answer receiving the most upvotes was:
Paraphrased from Brian Button:
- They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell.
- They violate the Single Responsibility Principle: by virtue of the fact that they control their own creation and life-cycle.
- They inherently cause code to be tightly coupled. This makes faking them out under test rather difficult in many cases.
- They carry state around for the lifetime of the app. Another hit to testing since you can end up with a situation where tests need to be ordered which is a big no no for unit tests. Why? Because each unit test should be independent from the other.
I agree with him on that. In cases, where such a dependency is not obvious by the classes name, the dependency should be injected. Injecting Singleton Instances into classes proves a wrong usage of the pattern.
All Objects need to control their life-cycle in a way. All objects need to have a constructor/destructor. This is even more true in non-managed languages such as C++/Objective-C where you are responsible of releasing your collaborators (Java and .NET programmers tend to forget that). A Singleton’s life-cycle is assumed to be the same as the application’s, so I don’t see the need to “control” that here. Most Singleton implementations are using a lazy-load mechanism to instantiate themselves. This is trivial and their life-cycle is unlikely to change, or else you shouldn’t use Singleton.
The GoF Singleton Pattern description includes the following: (p.128, Consequences 3.)
“Permits refinement of operations and representation. The Singleton class may be subclassed, and it’s easy to configure an application with an instance of this extended class. You can configure the application with an instance of the class you need at run-time“.
Contrary to static classes, Singleton Instances are normal classes and can therefore inherit from base classes and/or implement interfaces. In order to make a Singleton Instance swappable, you can either choose to inject (“initialize”) a “to-be-Singleton Instance” into the Singleton or lazy-load it based on some configuration info. Throwing exceptions on requests made before the Singleton Instance was initialized (and optionally, when an attempt is made to reinitialize it) ensures the same semantic behaviour as that of a simple Singleton Class. Eventually, this is no different from how an IoC Container would deal with Objects whose lifetime shall be that of a Singleton.
If your Singleton carries a significant global state, don’t use Singleton. This includes persistent storage such as Databases, Files etc. Note that log files are an exception to that. In most cases their state isn’t significant for the behaviour of the Application. Good examples for the usage of Singletons are PrintSpoolers (fire and forget).