Resist the temptation of the Singleton Pattern

Resist the temptation of the Singleton Pattern

Sam Saariste

The SiNGLETON PATTERN solves many of YOUR problems. You know the need a single instance. You had a guarantee that this instance is initialized before it ' s used. It keeps your design simple by has a global access point. It ' s all good. What's the not-to-do about this classic design pattern?

Quite a lot, it turns out. Tempting they is, but experience shows the most singletons really does more harm than good. They hinder testability and harm maintainability. Unfortunately, this additional wisdom was not as widespread as it should was, and singletons continue to being irresistible to Many programmers. But they is worth resisting:
? The single-instance requirement is often imagined. In many cases, it's pure speculation that no additional instances would be needed in the future. Broadcasting such speculative properties across an application ' s design are bound to cause pain at some point. Requirements'll change. Good design embraces this. singletons don ' t.
? singletons cause implicit dependencies between conceptually independent units of code. This was problematic both because they is hidden and because they introduce unnecessary coupling between units. This code smell becomes pungent if you try to write unit tests, which depend on loose coupling and the ability to select Ively Substitute a mock implementation for a real one. Singletons prevent such straightforward mocking.
? Singletons also carry implicit persistent state, which again hinders unit testing. Unit testing depends on tests being independent of one another, so the tests can is run in any order and the program can B E set to a known state before the execution of every unit test. Once you has introduced singletons with the mutable state, this may be hard to achieve. In addition, such globally accessible persistent state makes it harder to reason on the code, especially in a multithre aded environment.
?? 146 things every Programmer should Know
?
???????????????? Multithreading introduces further pitfalls to the singleton pattern. As Straight-forward locking on access isn't very efficient, the so-called double-checked locking pattern (DCLP) has gain Ed in popularity. Unfortunately, this could be a further form of Fatal attraction. It turns out this in many languages, DCLP was not thread-safe and, even where it was, there was still opportunities to get I T subtly wrong.
The cleanup of singletons may present a final challenge:
? There is no support for explicitly killing singletons. This can is a serious issue in some contexts-for example, in a plug-in architecture where a plug-in can is only safely UNL Oaded after all its objects has been cleaned up.
? There is No. order to the implicit cleanup of singletons at program exit. This can is troublesome for applications the contain singletons with interdependencies. When shutting-such applications, one Single-ton may access another that have already been destroyed.
Some of these shortcomings can be overcome by introducing additional mechanisms. However, this comes at the cost of additional complexity in code that could has been avoided by choosing an alternative D Esign.
Therefore, restrict your use of the Singleton pattern to the classes that truly must never is instantiated more than once. Don ' t use a singleton's global access point from arbitrary code. Instead, direct access to the singleton should come from only a few well-defined places, from where it can be passed Aroun D via its interface to other code. This other code was unaware, and so does not depend on whether a singleton or any other kind of class implements the Interf Ace. This breaks the dependencies that prevented unit testing and improves the main-tainability. So, the next time is thinking about implementing or accessing a singleton, I hope you ' ll pause and think again.

Resist the temptation of the Singleton Pattern