Funny how some sub­jects seem to attract catchy titles like flies. A lot of very clever peo­ple have writ­ten vol­umes about “The Sim­ple­ton Pat­tern”, and “Sin­gle­toni­tis” (bah, dead link, let’s use this instead then).

Many peo­ple are in love with the Sin­gle­ton pat­tern. Oth­ers — a small minor­ity, I sus­pect — con­sider it a mis­take, an anti-pattern, or some­thing that was only ever included in the Design Pat­terns book as a life­line to pro­ce­dural pro­gram­mers who couldn’t really fig­ure out this OOP thing.

I won’t pre­tend to be half as clever as all the peo­ple who have already writ­ten about the prob­lems with sin­gle­tons years ago, and I don’t think I have any­thing new to bring to the table. But it is a pat­tern I learned to loathe years ago. (Sin­gle­tons do sound attrac­tive when you first hear of them. But they pale a bit when you end up hav­ing to tear up and rewrite half your code just because all your sin­gle­ton classes start reveal­ing their short­com­ings) And for a long time now, I’ve tried to con­vince other pro­gram­mers that Sin­gle­tons have some seri­ous prob­lems. Recently, it seems like I’m even get­ting noticed for it among the users of StackOverflow.

First, oneuser posts an answer to one ques­tion, and I com­ment with a mild dis­agree­ment, and the dis­cus­sion goes on for a few more com­ments. As sin­gle­ton rants go, this one is pretty mild, and I don’t really think about it any fur­ther. Then, a few weeks later, I dis­cover his blog and this post. Wow! A con­vert. A per­son I know to be a smart and a knowl­edge­able pro­gram­mer has changed his mind in response to some­thing I said… I’m flattered.

And today, I noticed another ques­tion being posted, which had both Boost and Sin­gle­tons in the title — how could I resist? Two sub­jects I enjoy talk­ing about, even if the things I say about them are very dif­fer­ent. Sur­pris­ingly, the com­ments there already men­tioned me, and some of my ear­lier answers regard­ing sin­gle­tons. Should I be flat­tered or wor­ried that peo­ple have started bring­ing my name up when dis­cussing Singletons?

Any­way, one of the com­ments also sug­gested I write a blog post describ­ing my argu­ment in detail. So I will. I’ll even throw in a redi­rect link from http://jalf.dk/singleton, to make it as easy as pos­si­ble to find.

Two wrongs don’t make a right

There are a lot of prob­lems with sin­gle­tons. In fact, it’s sur­pris­ing that so many peo­ple still con­sider the pat­tern use­ful, when it is afflicted with so many weak­nesses and flaws. How­ever, for now I will sin­gle out the two that I feel are the most fun­da­men­tal: not just prob­lems with how a sin­gle­ton works, but with what they’re try­ing to achieve:

A sin­gle­ton, as defined by the Gang of Four, com­bines two properties:

• it guar­an­tees that exactly one instance of an object exists. While that one instance is typ­i­cally cre­ated lazily, so it doesn’t tech­ni­cally exist through­out the entire application’s life­time, it always seems to the pro­gram­mer as if pre­cisely one instance exists, and
• it guar­an­tees global access to this one instance.

Let’s pick those apart a bit. The last one is eas­i­est: it is, by now, fairly com­mon knowl­edge that global state is bad. We don’t like global vari­ables, we don’t like sta­tic class mem­bers, we don’t like any­thing that makes it harder to iso­late bits of our code. Depen­dence on global state causes a lot of prob­lems: it hurts par­al­lelism, as access to global muta­ble state gen­er­ally has to be seri­al­ized through the use of locks. It makes depen­den­cies harder to detect and con­trol (any func­tion might silently decide to access our sin­gle­ton. The func­tion sig­na­ture says noth­ing about this, so we have to read the source code of the func­tion to deter­mine if this is the case. And because it is so con­ve­nient to always just add a ref­er­ence to a sin­gle­ton, we tend to do it a lot. When you have a sin­gle­ton, you quickly end up in a sit­u­a­tion where three out of four classes depend on it. How did that hap­pen? Why, log­i­cally speak­ing, do so many classes need direct access to the data­base? Or the ren­derer? Is that good design? Not only is this messy, it’s also painfully hard to fix after the fact. Once we have these depen­den­cies on global objects every­where, that’s a lot of code we need to change to elim­i­nate the global. Almost every class will be impacted by the change, and a huge num­ber of func­tions have to have their sig­na­tures mod­i­fied to take that extra para­me­ter replac­ing the global. Or even worse, the func­tion has to be com­pletely rewrit­ten to elim­i­nate the need for what­ever ser­vice the sin­gle­ton pro­vided. The more glob­als you have in your project, the more your depen­dency graph starts resem­bling spaghetti. And the harder it gets to clean it up.

It hurts reusabil­ity, as code taken from one project and inserted into another may break because it depended on glob­als not present in the new project. It hurts testa­bil­ity partly for the same rea­son, a unit test test­ing a class must sud­denly pro­vide a num­ber of glob­als as well just for the code under test to com­pile, but also because global state makes tests less deter­min­is­tic. One test might change the state of this global, affect­ing the out­come of the next test to run.

Glob­als are bad for a lot of rea­sons. They have their uses, no doubt about that, but we should be sus­pi­cious when­ever the solu­tion to a prob­lem involves global data. It might be the best solu­tion, but often, it is more trou­ble than it’s worth.

The other point is more sub­tle. Why do I object to a class enforc­ing that “only one instance may exist”? It’s really just com­mon sense. As the Agile move­ment tells us, we don’t really know what our code is going to look like tomor­row. Over the course of devel­op­ment, we have to adapt to changes, mod­ify our code, revise deci­sions already made. Why put road­blocks in front of us? Why make it harder to adapt to unfore­seen changes or requirements?

Today, I might think that I need only one log­ger instance. But what if I real­ize tomor­row that I need two? That’s not so far fetched. We may have one log we write ad-hoc mes­sages intended for debug­ging pur­poses, solely to be read by devel­op­ers, and another for­mal­ized log, where struc­tured mes­sages are writ­ten when pre­de­ter­mined events occur, so that the appli­ca­tion can be mon­i­tored in pro­duc­tion. Sure, we could define the two as com­pletely sep­a­rate classes, and then we’d only need one instance of each (but then we’d start dupli­cat­ing code). Or we could use the same log instance to write to both logs (but then the log­ging code would become more com­plex, hav­ing to inter­leave two sep­a­rate and non-overlapping logs.

Once we’ve accepted that an appli­ca­tion may need more than one log­ger, shouldn’t we do our­selves the favor of ensur­ing that our log­gers can be instan­ti­ated more than once, just in case it turns out to be the right thing to do? We’re not even adding any com­plex­ity, there’s no cost asso­ci­ated with this. On the con­trary, we’re remov­ing sig­nif­i­cant com­plex­ity. Thread-safe sin­gle­tons are sur­pris­ingly hard to get right. Depen­den­cies between sin­gle­tons are tricky and cir­cu­lar ones can cause them to blow up in all sorts of fun ways. And let’s not even get into how to han­dle any­thing our sin­gle­tons might do while the appli­ca­tion is shut­ting down. What if the data­base sin­gle­ton tries to write a sim­ple “good­bye” log mes­sage to the log sin­gle­ton? What if the log sin­gle­ton got destroyed before the data­base one? Ouch.

Sin­gle­tons are hard to write and hard to use. Remov­ing them only sim­pli­fies our code, so if it also enables us to bet­ter adapt to unfore­seen require­ments, why shouldn’t we remove them?

Not con­vinced? Let’s think of some other exam­ples then:

• the appli­ca­tion con­fig­u­ra­tion should be a sin­gle­ton, right? We obvi­ously can’t have more than one of those! Wrong. We can. We often do. Think about what hap­pens when the user opens the “Options” screen and mod­i­fies the set­tings. Dur­ing that time, two sets of set­tings exist: the “applied” set­tings that are cur­rently in effect, and the “spec­u­la­tive” ones, cur­rently being picked out by the user. Once he clicks OK, the spec­u­la­tive changes should be applied, replac­ing the ones that were pre­vi­ously in effect. But until then, we have two sets of set­tings to maintain.
• a data­base con­nec­tion pool then! If we have more than one pool of con­nec­tions, we can’t effi­ciently share them! Cor­rect, but per­haps we don’t want to share them. Per­haps I want to ensure that library A has one pool of 10 con­nec­tions avail­able to it, com­po­nent B has a smaller pool of 3 con­nec­tions, an com­po­nents C, D and E use the global pool with how­ever many con­nec­tions it sup­plies. That would ensure that no mat­ter the num­ber of threads run­ning in com­po­nent B, it’ll never starve out other com­po­nents try­ing to access the data­base. It can never hold more than three con­nec­tions, leav­ing room for other com­po­nents. Of course, in the com­mon case, we do want all con­nec­tions to be shared in one sin­gle pool. But per­haps not always. So yes, there should prob­a­bly be a glob­ally acces­si­ble default pool avail­able. But why shouldn’t it also be pos­si­ble to define new local pools if the user deems it nec­es­sary? Why limit our­selves 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 crash­ing down on us, con­sider test­ing. Con­sider that each of your unit tests should set up the envi­ron­ment it needs, and run within that envi­ron­ment, in iso­la­tion from other tests. That means that every test should cre­ate its own log­ger instance, or data­base pool instance, or what­ever else our sin­gle­tons are doing, just so it can avoid being pol­luted by state­ful changes made by ear­lier tests. Each unit test for the Direct3D ren­derer should set up its own ren­derer object. Each physics sim­u­la­tion test should ini­tial­ize the physics engine first, and shut it down again after use. Sin­gle­tons don’t eas­ily allow that. Sure, we can extend them with explicit Create() and Destroy() meth­ods, but then our abstrac­tion is start­ing to get leaky. We can no longer assume that pre­cisely one instance exists, because we might have just destroyed the one that existed.

The “exactly one instance” guar­an­tee removes flex­i­bil­ity from our code that we may need, in order to enforce a con­straint that we def­i­nitely don’t need. Where’s the harm in allow­ing the user to cre­ate more than one instance if he decides to?

C++ pro­gram­mers are famil­iar with std::cout, the stan­dard out­put stream. Funny thing about this, it is a sim­ple global object. We can obvi­ously never have more than one stan­dard out­put stream. But we can have more than one stream. The stan­dard library just ini­tial­izes one of them to point to the stan­dard out­put, and saves it as a global vari­able. We don’t need it to be a sin­gle­ton, we don’t even need it to be a sta­tic class spe­cially defined for the pur­pose. We just need a stream, defined some­where where it’s glob­ally accessible.

True, a suf­fi­ciently stu­pid pro­gram­mer could cre­ate a new stream when he intended to write to std::cout, and true, a sin­gle­ton imple­men­ta­tion would have pre­vented that. But is it worth it? When was the last time you saw some­one acci­den­tally invoke std::ostream() << "Hello world";, when they intended to write std::cout << "Hello world";? It’s not the most com­mon typo I’ve seen.

We don’t need to pre­vent mul­ti­ple instan­ti­a­tions. If we want only one instance, we just instan­ti­ate the class once, and refer to that instance when­ever we need it, end of story. We don’t need the com­piler to slap us over the wrists if we do cre­ate mul­ti­ple instances, because we never do so by mis­take. If we do it, it’s because we have a rea­son. It’s because our ini­tial assump­tion that only one instance was needed, turned out to be wrong!

So there you have it. A sin­gle­ton com­bines two neg­a­tive qual­i­ties. It takes the “you can never cre­ate a sec­ond instance of this class” con­straint, which hardly ever makes sense, and even when it does, does not typ­i­cally need to be enforced by the com­piler, and com­bines it with a global object, giv­ing us all the down­sides 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 com­bined with another bad thing, cre­at­ing a very bad thing.

Too many pro­gram­mers rely heav­ily on sin­gle­tons to solve a prob­lem they never had. They never needed a compile-time guar­an­tee that mul­ti­ple instances of a class can never be cre­ated. They just needed one instance to be created.

Some­times, we do need glob­als, yes. In those cases, make old-fashioned glob­als. Use sta­tic class mem­bers, or if the lan­guage allows it, global (non-member) objects. Or use the Mono­state pat­tern, or what­ever you feel is the clean­est solu­tion. But remem­ber that the prob­lem you’re try­ing to solve is “enabling global access to this data”. No more, no less. You do not want a solu­tion which sneaks com­pletely unre­lated con­straints and lim­i­ta­tions in through the back door.

And while I can’t per­son­ally think of many cases where this is true, you might also run into sit­u­a­tions where it is truly nec­es­sary to pre­vent more than one instance of a class from ever exist­ing. Again, I can’t think of what sit­u­a­tion this might be, but I won’t rule out that it can occur. If it does, then enforce that con­straint alone. But don’t go around pro­vid­ing global access to the object as well. What­ever spe­cial­ized pur­pose your “one instance only” class serves, it’s highly unlikely that every­one should be allowed access to it. So don’t make it a global.

Most of the time, your classes should have nei­ther of these attrib­utes. Some­times, rarely, they may need one of them. But the sin­gle­ton pat­tern imbues the class with both prop­er­ties, and that is just a plain bad idea.

Tags: c++, design patterns, singleton, stackoverflow

Programming | RSS 2.0 | Respond | Trackback |