Collective Wisdom from the Experts 147
- ultithreading introduces further pitfalls to the singleton pattern. M As straight-
forward locking on access is not very efficient, the so-called double-checked
locking pattern (DCLP) has gained in popularity. Unfortunately, this may
be a further form of fatal attraction. It turns out that in many languages,
DCLP is not thread-safe and, even where it is, there are still opportunities
to get it subtly wrong.
The cleanup of singletons may present a final challenge:
- There is no support for explicitly killing singletons. This can be a serious issue
in some contexts—for example, in a plug-in architecture where a plug-in
can only be safely unloaded after all its objects have been cleaned up. - There is no order to the implicit cleanup of singletons at program exit.
This can be troublesome for applications that contain singletons with
interdependencies. When shutting down such applications, one single-
ton may access another that has 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 have been avoided by choosing an alternative design.
Therefore, restrict your use of the Singleton pattern to the classes that truly
must never be 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 around via its
interface to other code. This other code is unaware, and so does not depend on
whether a singleton or any other kind of class implements the interface. This
breaks the dependencies that prevented unit testing and improves the main-
tainability. So, the next time you are thinking about implementing or accessing
a singleton, I hope you’ll pause and think again.