1 Christopher Alexander and his team defined the original meaning in the context of architecture as follows:
“Each pattern describes a problem which occurs over and over again in our environment, and then describes
the core of the solution to that problem, in such a way that you can use this solution a million times over,
without ever doing it the same way twice.” (A Pattern Language, Christopher Alexander et al., 1977, p. x). We
think this definition works for the patterns we describe in this book, except that we probably don’t have as
much variability in our solutions.
Design Patterns
The concept of design patterns dates back to the 1970s and from the field of architec‐
ture. Christopher Alexander, an architect and system theorist, and his team published
the groundbreaking A Pattern Language (Oxford University Press) in 1977, which
describes architectural patterns for creating towns, buildings, and other construction
projects. Sometime later this idea was adopted by the newly formed software indus‐
try. The most famous book in this area is Design Patterns—Elements of Reusable
Object-Oriented
Soware by Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides—the Gang of Four (Addison-Wesley). When we talk about the famous Sin‐
gleton, Factories, or Delegation patterns, it’s because of this defining work. Many
other great pattern books have been written since then for various fields with differ‐
ent levels of granularity, like Enterprise Integration Patterns by Gregor Hohpe and
Bobby Woolf (Addison-Wesley) or Patterns of Enterprise Application Architecture by
Martin Fowler (Addison-Wesley).
In short, a pattern describes a repeatable solution to a problem.
1
It is different from a
recipe because instead of giving step-by-step instructions to solving a problem, a pat‐
tern provides a blueprint for solving a whole class of similar problems. For example,
the Alexandrian pattern “Beer Hall” describes how public drinking halls should be
constructed where “strangers and friends are drinking companions” and not “anchors
of the lonely.” All halls built after this pattern look different, but share common char‐
acteristics such as open alcoves for groups of four to eight and a place where a hun‐
dred people can meet with beverages, music, and other activities.
However, a pattern does more than provide a solution. It is also about forming a lan‐
guage. The unique pattern names form a dense, noun-centric language in which each
pattern carries a unique name. When this language is established, these names auto‐
matically evoke similar mental representations when people speak about these pat‐
terns. For example, when we talk about a table, anyone speaking English assumes we
are talking about a piece of wood with four legs and a top on which you can put
things. The same thing happens in software engineering when we talk about a “fac‐
tory.” In an object-oriented programming language context, we immediately associate
with a “factory” an object that produces other objects. Because we immediately know
the solution behind the pattern, we can move on to tackle yet unsolved problems.
xii | Preface