Niclas Nilsson home

The Highlander Pattern

Originally written around February 2005, when I was involved in creating a software product line which we nicknamed “Highlander”. The name (or rather the reason we choose the name) reminded me of a discussion that I had had several times over the years.

Do you find yourself using the Singleton pattern a lot? Or do you occasionally read code that seems to use Singletons where it seems awkward? In that case you may recognize the following discussion.

I’ve had the following discussion a number of times when I’ve found an object wrapped in a Singleton and I didn’t understand why. For example, there may currently be one network connection available to your system and that connection is a Singleton. I ask the developer:

- “Why did you wrap this object in a Singleton?”

- “Oh, that’s because we only have one network connection to the system, and if I wrap it in a Singleton there is an easy access to it. Don’t you know about Singletons?”

- “Well, yes, I do know about Singletons. But what are you going to do if or when the system gets another network connection for some reason?”

- “That’s never going to happen. There is no need for a second network connection.”

But things change, and they change in ways you don’t expect. In all cases so far, I have been able to come up with a very realistic example of why there may very well be another instance of the thing that is currently wrapped in a Singleton. I guess that’s the reason I asked in the first place instead of leaving it be.

However, this kind of argumentation has gotten tricker the last few years. The last sentence in the conversation above is nowadays at times changed to:

- “We just refactor the code if or when that happens. I’ll do it as simple as possible at each given time, and right now, I only have to care about one instance, and Singleton is the easiest way.”

This is of course true (and yes, sometimes the agile arguments comes right back at you). We should not build anything that is not used, we should strive for the easiest solution (but not oversimplify), but in this case I just don’t agree. And the reason I don’t agree is that I think there is another reason behind this kind of Singleton abuse.

The Singleton pattern seems to be the first pattern that people learn, and it appears to be a very appreciated pattern. I’ve also met a few people who only knows about this pattern and not about any other patterns. So, Singleton has definitely made a much larger impact than other patterns.

The reason for this may be that it is a very easy pattern to learn and it stands well by itself. It does not need support by other patterns to be useful or understood. Also, most developers doesn’t study software development that much (less than one book a year, as an average) - they do as their peers do. Looking at your peers is a good thing, but it does not always (even seldom, unfortunately?) give you an insight in why they did as they did, only how. Still, Singletons gets around to almost everyone, while other patterns doesn’t seem to spread as well.

I’ve come to a possible conclusion of the reason for this, a reason that makes me feel a bit uneasy. I suspect that some developers sees something in the Singleton pattern that they lost a long time ago, something they’ve been longing for since the minute they lost it. The long lost Global Variables…

Suddenly, there is a way to use global variables without getting yelled at by your coworkers, and even in languages where the language designers “forgot” to put them in. Patterns are good things, and no sane coworker will ever complain about you using patterns, will they?

Well… they will. If something is used in the wrong way, I really hope the coworkers will give you a hint of their opinions. Otherwise, the team is in “hype-mode” where nothing can be wrong with a certain technique/buzzword. Using Singletons to fake global variables is not a good thing. To me, it is bad design, and it also makes code reuse a lot harder. Not as hard as normal global variables, but very close. The only difference it that you tie your code to a particular class name instead of a particular instance name. And when it is used as global variables, then all the same problems that global variables gave you are back again.

Don’t get me wrong. I think Singleton is a very nice pattern when it used for its intended purpose and not for emulating global variables. The book Design Patterns states the intent as “Ensure a class only has one instance, and provide a global point of access to it”. That is, use this pattern when having more than one instance of a particular class is dead wrong within this system. Use it when you need to protect a class from being instantiated twice, when it really represents a shared resource and the system would crash and burn if there is ever more than one instance. Highlander and The Highlander pattern

Do you still remember the title of this article? Why did I call this article “The Highlander pattern”?

In the movie Highlander there is a cool quote, a quote which (apart from being cool and a central part of the movie) also happens to communicate exactly what the Singleton pattern is all about. Therefore, I hereby would like to give the Singleton pattern an alias - The Highlander pattern.

The quote? “There can be only one!”