Pattern Hatching has three main thrusts. First off, it's about putting design patterns to work. The most common queries from readers of DesignPatterns have been when, where, and how best to apply patterns in the development process. I've tried to address those questions in Pattern Hatching by presenting a variety of approaches to pattern application. That includes unprofitable approaches as well as profitable ones, because design by counterexample can be just as enlightening as design by example. There's lots of both kinds of design in PatternHatching.

Besides teaching pattern application, I spend a good chunk of the book extending some of the original GoF patterns. There is substantial value-add on Memento, Observer, Singleton, and (of course) Visitor.
I've also
included a brand-new pattern called Generation Gap, which didn't appear in DesignPatterns because of a dearth of known uses. Now, however, thanks to the feedback of many kind people, we have more than enough known uses to brand it a bona fide design pattern. Generation Gap describes a simple way to integrate generated and hand-crafted code while avoiding common maintenance problems of such integration. Many who write code generators of all sorts---from CORBA stub generators to graphical user interface builders to 4GL compilers---will find this pattern invaluable.

A third thrust of the book is to help those who want to write their own patterns. I do that in two ways. The last chapter offers advice in the form of seven "habits" that promote effective pattern writing. It was an obvious way to articulate the subtleties of good pattern writing, but it's also fairly abstract---lots of dos and don'ts. So I offer something more concrete as well: a behind-the-scenes look at the development of a another new pattern, Typed Message. I chronicle the exchanges we Gang of Four had as this pattern evolved, including all the debates, false starts, and virtual hand-wringing that went on. It's the most tangible way I could think of to convey the heart of our pattern-writing process.

You can think of Pattern Hatching as a commentary on DesignPatterns, or perhaps as a companion that enhances and updates it. Pattern Hatching is also reminiscent of "The Making of So-and-So" films, to the extent that it reveals our pattern-writing process in particular. However, the point here is not to entertain people but to help them better understand what makes a design pattern useful. There's more than one way to benefit from patterns. Being able to capture your own expertise in pattern form is one of the more potent and elusive ways.

Another thing I felt important to do in this book was to counter the fanaticism that patterns can engender. I've seen people use patterns to produce complex, overwrought, incomprehensible designs---designs that can do lots of things slowly but almost nothing well. I've witnessed aspiring pattern writers finding "patterns" under every rock. Novices are all-too-often desperate to follow a pattern to the letter, no matter how nonsensical that may be. Others get infatuated with pattern lore and personalities, particularly the smartest ones who experience immediate success with them.

We must keep patterns in perspective; otherwise they are bound for the ash heap of hype, where so many once-ballyhooed concepts end up. I wanted Pattern Hatching to bring patterns down to earth where they belong. I think Jim Coplien says it best in the Foreword: "[PatternHatching] will help you understand how the GoF book---and, indeed, any collection of design patterns---can be a treasured guide without being a burdensome prescription."

Who is this book targeted to help?

Software developers, technical managers, computer science students, and pattern aficionados should find Pattern Hatching useful and enjoyable. My hope is that the pattern application, pattern enhancement, and pattern writing thrusts of this book will make it as broadly appealing as DesignPatterns is, if not more so.