Introduction

This book is for curious software developers of all types. It doesn’t matter which language you use and the industry you work in is irrelevant; what does matter is your interest in why things are the way they are. You will find much more than object-oriented design patterns here as the problem we face is far broader.

This book is for developers who have heard of, used, or even read up on design patterns but think something is missing or needs correcting. It is also for those who wish to know why this can still be the case. Furthermore, it is for those individuals who love design patterns and want to know how to extend their benefits. This book is for developers with little to no experience in design patterns who wish to avoid their pitfalls, and it can benefit anyone who has worked with patterns for a while but was surprised when their purported values did not emerge. It is for those who like the design on the cover and think it would look nice on their bookshelf.

In these pages, I hope you will find practical tips and useful takeaways, but this is not a how-to manual. Instead, think of this as a book that explains the principles you can use in the following ways:

• To build a toolkit of techniques to dissect existing patterns
• To learn how you can better repair broken things when you see them
• To uncover ways to correctly identify whether they are broken in the first place.

In short, if you have opinions on design patterns, this book can help you justify them. If you don’t, you might just begin to develop some. Additionally, as a bonus, you will discover how to get the most out of them, regardless of their flaws.

As the story unfolds, the foremost players will be an architect, a small group of software developers, a movement populated by hundreds of developers, and the way in which the world reinforces our actions.

The architect

Christopher Alexander was the architect. He was the central character for the initial discovery of patterns and set the course of pattern history. Although he wasn’t a software developer by any means, he was fascinated by the possibilities presented by developing software using a pattern-language approach. His book A Pattern Language[APL77] became famous among software developers and was the basis for the formation of design patterns in software. However, his story takes its first and most consequential step with the much earlier book Notes on the Synthesis of Form[Notes64], which was written back in 1964 when he was still an academic.

The software developers

A small group of software developers became known as the Gang of Four, often abbreviated to the GoF. Together, in 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides produced an incredibly successful book called Design Patterns: Elements of Reusable Object-Oriented Software[GoF94], which detailed 23 software design patterns for object-oriented programmers to learn and use. This best-selling work is often called the ‘GoF book’, and that is how I shall refer to it throughout this work.

The movement

The software-design-patterns movement was real and still exists to this day, but it is now far more low-key. At its height, hundreds of developers contributed to it and spread the word to anyone who would listen. In addition, the movement rippled out into other areas of development, such as education, and organisational change. As the hype receded, only a few remained faithful to the broader pattern movement.

The world

The last component of the story is the world itself and how natural laws of emergent behaviour clashed with many of the expectations and needs of those involved. This final element—the emergent behaviour of complex systems—brings us back to the start. Christopher Alexander’s first work sought to tame complexity in intensely interconnected projects and guide the emergent properties of larger systems to positive conclusions.

Our journey

During this voyage, I must reference patterns from software development and physical architecture. The majority of the physical architecture patterns identified by Christopher Alexander and his colleagues are from the book A Pattern Language. As they are numbered in that book, I will reference them as follows: 202 Built-in Seats. The software design patterns in the GoF book do not have numbers, so I will reference them in the following manner: Strategy. Not to spoil the surprise, but other software design patterns will also be referenced in the same way. At the end of the book, there are summaries of most of the patterns that are mentioned to help those less familiar with the subject; however, they are my summations, so you may still want to obtain a copy of each book to fully comprehend the patterns held within.

Before we begin the journey, we should take a look at the road map. In the rest of this introduction, I intend to highlight the kinds of questions that I later attempt to answer—this is so that you know where we’re going. The terrain will get a little rough at times—and there are no well-worn tracks in many places; unfortunately, this means that it will be necessary to explain some of the historical and theoretical elements of the topic along the way. I won’t try to convince you of anything nor attempt to directly answer any questions in the remainder of this introduction; only clarify what I intend to address by the end of the book.