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
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
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
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.