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 Software  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. 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. xii  |  Preface