Many people are in love with the Singleton pattern. Others — a small minority, I suspect — consider it a mistake, an anti-pattern, or something that was only ever included in the Design Patterns book as a lifeline to procedural programmers who couldn’t really figure out this OOP thing.

I won’t pretend to be half as clever as all the people who have already written about the problems with singletons years ago, and I don’t think I have anything new to bring to the table. But it is a pattern I learned to loathe years ago. (Singletons do sound attractive when you first hear of them. But they pale a bit when you end up having to tear up and rewrite half your code just because all your singleton classes start revealing their shortcomings) And for a long time now, I’ve tried to convince other programmers that Singletons have some serious problems. Recently, it seems like I’m even getting noticed for it among the users of StackOverflow.

First, oneuser posts an answer to one question, and I comment with a mild disagreement, and the discussion goes on for a few more comments. As singleton rants go, this one is pretty mild, and I don’t really think about it any further. Then, a few weeks later, I discover his blog and this post. Wow! A convert. A person I know to be a smart and a knowledgeable programmer has changed his mind in response to something I said… I’m flattered.

And today, I noticed another question being posted, which had both Boost and Singletons in the title — how could I resist? Two subjects I enjoy talking about, even if the things I say about them are very different. Surprisingly, the comments there already mentioned me, and some of my earlier answers regarding singletons. Should I be flattered or worried that people have started bringing my name up when discussing Singletons?

Anyway, one of the comments also suggested I write a blog post describing my argument in detail. So I will. I’ll even throw in a redirect link from http://jalf.dk/singleton, to make it as easy as possible to find.

Two wrongs don’t make a right

There are a lot of problems with singletons. In fact, it’s surprising that so many people still consider the pattern useful, when it is afflicted with so many weaknesses and flaws. However, for now I will single out the two that I feel are the most fundamental: not just problems with how a singleton works, but with what they’re trying to achieve:

A singleton, as defined by the Gang of Four, combines two properties:

• it guarantees that exactly one instance of an object exists. While that one instance is typically created lazily, so it doesn’t technically exist throughout the entire application’s lifetime, it always seems to the programmer as if precisely one instance exists, and
• it guarantees global access to this one instance.

Let’s pick those apart a bit. The last one is easiest: it is, by now, fairly common knowledge that global state is bad. We don’t like global variables, we don’t like static class members, we don’t like anything that makes it harder to isolate bits of our code. Dependence on global state causes a lot of problems: it hurts parallelism, as access to global mutable state generally has to be serialized through the use of locks. It makes dependencies harder to detect and control (any function might silently decide to access our singleton. The function signature says nothing about this, so we have to read the source code of the function to determine if this is the case. And because it is so convenient to always just add a reference to a singleton, we tend to do it a lot. When you have a singleton, you quickly end up in a situation where three out of four classes depend on it. How did that happen? Why, logically speaking, do so many classes need direct access to the database? Or the renderer? Is that good design? Not only is this messy, it’s also painfully hard to fix after the fact. Once we have these dependencies on global objects everywhere, that’s a lot of code we need to change to eliminate the global. Almost every class will be impacted by the change, and a huge number of functions have to have their signatures modified to take that extra parameter replacing the global. Or even worse, the function has to be completely rewritten to eliminate the need for whatever service the singleton provided. The more globals you have in your project, the more your dependency graph starts resembling spaghetti. And the harder it gets to clean it up.

It hurts reusability, as code taken from one project and inserted into another may break because it depended on globals not present in the new project. It hurts testability partly for the same reason, a unit test testing a class must suddenly provide a number of globals as well just for the code under test to compile, but also because global state makes tests less deterministic. One test might change the state of this global, affecting the outcome of the next test to run.

Globals are bad for a lot of reasons. They have their uses, no doubt about that, but we should be suspicious whenever the solution to a problem involves global data. It might be the best solution, but often, it is more trouble than it’s worth.

The other point is more subtle. Why do I object to a class enforcing that “only one instance may exist”? It’s really just common sense. As the Agile movement tells us, we don’t really know what our code is going to look like tomorrow. Over the course of development, we have to adapt to changes, modify our code, revise decisions already made. Why put roadblocks in front of us? Why make it harder to adapt to unforeseen changes or requirements?

Today, I might think that I need only one logger instance. But what if I realize tomorrow that I need two? That’s not so far fetched. We may have one log we write ad-hoc messages intended for debugging purposes, solely to be read by developers, and another formalized log, where structured messages are written when predetermined events occur, so that the application can be monitored in production. Sure, we could define the two as completely separate classes, and then we’d only need one instance of each (but then we’d start duplicating code). Or we could use the same log instance to write to both logs (but then the logging code would become more complex, having to interleave two separate and non-overlapping logs.

Once we’ve accepted that an application may need more than one logger, shouldn’t we do ourselves the favor of ensuring that our loggers can be instantiated more than once, just in case it turns out to be the right thing to do? We’re not even adding any complexity, there’s no cost associated with this. On the contrary, we’re removing significant complexity. Thread-safe singletons are surprisingly hard to get right. Dependencies between singletons are tricky and circular ones can cause them to blow up in all sorts of fun ways. And let’s not even get into how to handle anything our singletons might do while the application is shutting down. What if the database singleton tries to write a simple “goodbye” log message to the log singleton? What if the log singleton got destroyed before the database one? Ouch.

Singletons are hard to write and hard to use. Removing them only simplifies our code, so if it also enables us to better adapt to unforeseen requirements, why shouldn’t we remove them?

Not convinced? Let’s think of some other examples then:

• the application configuration should be a singleton, right? We obviously can’t have more than one of those! Wrong. We can. We often do. Think about what happens when the user opens the “Options” screen and modifies the settings. During that time, two sets of settings exist: the “applied” settings that are currently in effect, and the “speculative” ones, currently being picked out by the user. Once he clicks OK, the speculative changes should be applied, replacing the ones that were previously in effect. But until then, we have two sets of settings to maintain.
• a database connection pool then! If we have more than one pool of connections, we can’t efficiently share them! Correct, but perhaps we don’t want to share them. Perhaps I want to ensure that library A has one pool of 10 connections available to it, component B has a smaller pool of 3 connections, an components C, D and E use the global pool with however many connections it supplies. That would ensure that no matter the number of threads running in component B, it’ll never starve out other components trying to access the database. It can never hold more than three connections, leaving room for other components. Of course, in the common case, we do want all connections to be shared in one single pool. But perhaps not always. So yes, there should probably be a globally accessible default pool available. But why shouldn’t it also be possible to define new local pools if the user deems it necessary? Why limit ourselves to one instance?

And even if you do come up with some case where we absolutely must never have more than one instance, where it would make the sky come crashing down on us, consider testing. Consider that each of your unit tests should set up the environment it needs, and run within that environment, in isolation from other tests. That means that every test should create its own logger instance, or database pool instance, or whatever else our singletons are doing, just so it can avoid being polluted by stateful changes made by earlier tests. Each unit test for the Direct3D renderer should set up its own renderer object. Each physics simulation test should initialize the physics engine first, and shut it down again after use. Singletons don’t easily allow that. Sure, we can extend them with explicit Create() and Destroy() methods, but then our abstraction is starting to get leaky. We can no longer assume that precisely one instance exists, because we might have just destroyed the one that existed.

The “exactly one instance” guarantee removes flexibility from our code that we may need, in order to enforce a constraint that we definitely don’t need. Where’s the harm in allowing the user to create more than one instance if he decides to?

C++ programmers are familiar with std::cout, the standard output stream. Funny thing about this, it is a simple global object. We can obviously never have more than one standard output stream. But we can have more than one stream. The standard library just initializes one of them to point to the standard output, and saves it as a global variable. We don’t need it to be a singleton, we don’t even need it to be a static class specially defined for the purpose. We just need a stream, defined somewhere where it’s globally accessible.

True, a sufficiently stupid programmer could create a new stream when he intended to write to std::cout, and true, a singleton implementation would have prevented that. But is it worth it? When was the last time you saw someone accidentally invoke std::ostream() << "Hello world";, when they intended to write std::cout << "Hello world";? It’s not the most common typo I’ve seen.

We don’t need to prevent multiple instantiations. If we want only one instance, we just instantiate the class once, and refer to that instance whenever we need it, end of story. We don’t need the compiler to slap us over the wrists if we do create multiple instances, because we never do so by mistake. If we do it, it’s because we have a reason. It’s because our initial assumption that only one instance was needed, turned out to be wrong!

So there you have it. A singleton combines two negative qualities. It takes the “you can never create a second instance of this class” constraint, which hardly ever makes sense, and even when it does, does not typically need to be enforced by the compiler, and combines it with a global object, giving us all the downsides of both!

Two wrongs don’t make a right. Not even if they were described as a good idea by some guys 15 years ago. They’re still no greater than the sum of their parts: two wrongs. One bad thing combined with another bad thing, creating a very bad thing.

Too many programmers rely heavily on singletons to solve a problem they never had. They never needed a compile-time guarantee that multiple instances of a class can never be created. They just needed one instance to be created.

Sometimes, we do need globals, yes. In those cases, make old-fashioned globals. Use static class members, or if the language allows it, global (non-member) objects. Or use the Monostate pattern, or whatever you feel is the cleanest solution. But remember that the problem you’re trying to solve is “enabling global access to this data”. No more, no less. You do not want a solution which sneaks completely unrelated constraints and limitations in through the back door.

And while I can’t personally think of many cases where this is true, you might also run into situations where it is truly necessary to prevent more than one instance of a class from ever existing. Again, I can’t think of what situation this might be, but I won’t rule out that it can occur. If it does, then enforce that constraint alone. But don’t go around providing global access to the object as well. Whatever specialized purpose your “one instance only” class serves, it’s highly unlikely that everyone should be allowed access to it. So don’t make it a global.

Most of the time, your classes should have neither of these attributes. Sometimes, rarely, they may need one of them. But the singleton pattern imbues the class with both properties, and that is just a plain bad idea.