In my earlier post I mentioned that there are a couple of design patterns that I think are wholly wrong. The one that I'm most convinced is an abomination is the singleton pattern.

The basic idea is that you make a class that should only ever have one instance, and you provide that instance by storing it in a static (aka global) variable once it's made, so that everyone can get it easily.

There are lots of situations that this looks like it's going to save time. For example you might have a cache that you want everything to share. Or you may know that you only want one instance of the UI. You can save the effort of passing these things around, and all you need to do is call a static method from anywhere and you'll be given the instance.

But it's not going to save effort in the long run, because static state ruins everything:

Static state ruins readability
If you have a lump of code that doesn't read from any static state, you have to pass it any instances of things that it might change (preferably in its constructor). This is great documentation, giving you an overview of what influence a class can possibly have. Of course, there's so much static state in the world, you lose a lot of this already (the file system for starters), but there's no sense in making more.

Static state ruins testability
Automated testing of any kind is much easier if you can split up which parts of your system you are testing at any one time. To do this, you need to stop the bit you do want to test from starting and using the bits you don't want to test. Of course, you could scatter compiler directives in to choose whether to do things, but I reckon it's easier to just pass mock objects in, which pretend to be the rest of the system, but in fact just give the same results for every call (or even better, check that you're making the right calls).

Static state ruins refactoring
When refactoring, you know that you can take your code, and move it somewhere else, as long as you can get hold of all the things that it depends on. If you use static state, it's really hard to see where those dependencies are, and whether they'll be still there, and mean the same, in the code's new home.

Static state ruins expanding the system
 There have been so many times that I've written some code, and then a few weeks down the line realised that I need a similar component for a different job. It happens a lot in UI programming, where making life easy for the user is more important than avoiding redundant functionality. So, rather than copying the code, I can quickly make it more generic so it can cope with both tasks, and then use a second instance of it, passing it a different set of dependencies to deal with. If it had relied on static state, I would have had to unpick the dependencies from the code, and it probably wouldn't have been worth it.

If you want to expand your system to run in parallel (for example if it is processing web requests or something) all you need to do is make more instances of your class. No worries about thread safety until you know you really have to share something between them.

How bad is all this passing around going to get? I hate methods and constructors with lists of parameters as long as your arm. They're ugly, and mean that important details get lost. Passing things around does mean that classes that depend on lots of things get loads of constructor parameters. That's great, because then I know when a class is dealing with too many concepts and I need to take a knife to it.

So, never use the singleton design pattern, or static state at all.