There is only one book

Searching the web with questions like ‘How many design patterns are there?’ provides evidence for 22, 23, 26, or 30 patterns. You need to do a bit of digging into other sources before you find references to all the other books and repositories. For many, and I believe the vast majority of developers, there is only one book on design patterns. All the rest have been hidden from the mainstream behind the popularity and success of the GoF book[GoF94].

When developers learn about the GoF patterns, they can end up thinking that’s all there is, so they attempt to put all their different problem pegs in the same square solution holes. Some are square, so they fit and become examples of how good patterns can be.

But some are round, rectangular, or arched, and they still fit, but something is a bit off. The patterns are stretched, but the developer is still doing the right thing as far as they can tell. They have problems; they find a matching pattern solution. If the pattern seems slightly off, it’s ignored or assessed as the design pattern not being used properly.

But then, there are those problems that don’t fit into any of the solutions at all. At that point, the developer either thinks the problem is unsolvable or builds something convoluted. Because of how they learned about patterns, developers haven’t learned to solve problems, just apply solutions. There could be patterns out there to help solve the problem, but when you only know of 23, and you know there are only 23, why would you go looking?

Many problems are repeatedly re-solved because any patterns that could help are hidden behind the smoke screen produced from the fame of the GoF book. The book even managed to overshadow the significantly more nuanced Pattern-Oriented Software Architecture[POSA96] series, which is a great shame, as POSA was long-running and includes substantial improvements to the core concept of software design patterns.

It’s possible the GoF book had a positive effect at the time and caused many low-quality patterns to dissolve. The other pattern books lasted quite a while, staying around for a decade or so. Then, they went out of print, were ignored, or were used as examples of how the whole design pattern movement was a hype-driven marketing program to sell books and conference tickets.

The negative consequences of hype are hard to exaggerate. With a large proportion of the software development industry passively ignoring the available patterns, they were heading in the wrong direction. When academic institutes attempted to validate the patterns and found them wanting1, industry sceptics got the ammunition they needed to increase their ranks. The GoF book has been at the centre of a series of events, giving the whole movement a bad name.

But at least design patterns have a name.

They’re still around because the book was wildly successful. I’m writing about them because their ineffectiveness was a problem with real-world consequences for our teams and projects. In some cases, you could honestly say it was our fault for not reading the book thoroughly. However, when someone tells me I wasn’t following the instructions well enough, I refer them to Donald Norman or the Neilson group of usability experts and remind them that user error is not an indicator of a correction to be made to the user.

GoF categories boxed things in but still looked at the implementation side of many situations. When you consider Factory Method versus Strategy and wonder why one is creational and the other behavioural, are you claiming creating isn’t a behaviour? So much of the GoF Book stems from being an object-oriented design book. So much needs revising. And no, I’m not just talking about Singleton!

The consequences of the book are positive and negative. I’m sure Christopher Alexander had more sales of A Pattern Language[APL77] to programmers than he ever had to architects. I’m sure his net worth was higher because of the GoF. I’m also sure we’ve created an environment that is both hostile and receptive to new works in the design pattern space, but the name ‘design pattern’ is polluted. We turned design patterns into a way of describing recognisable constructs that fulfil a design need. We use the term to describe the structure of forms, web pages, and other ideas and arrangements in general. The term has lost its teeth.