Innovations Interviews John Vlissides on Patterns

We asked John Vlissides, co-author of Design Patterns CD: Elements of Reusable Object-Oriented Software and author of Pattern Hatching: Design Patterns Appliedto talk with us about his books and background.

In addition to teaching pattern application, I spend a good chunk of the book extending some of the original patterns found in Design Patterns. There are substantial new insights on Memento, Observer, Singleton, and (of course) Visitor. I've also included a brand-new pattern called Generation Gap, which didn't appear in Design Patterns 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 another new pattern, Typed Message. I chronicle the exchanges we Gang of Four [Erich Gamma, Richard Helm, Ralph Johnson, and myself] 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.

Innovations: How does this book apply to Design Patterns?
Vlissides: You can think of Pattern Hatching as a commentary on Design Patterns, 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 encountered aspiring pattern writers who find "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: "[Pattern Hatching] will help you understand how the GoF book [Design Patterns]—and, indeed, any collection of design patterns—can be a treasured guide without being a burdensome prescription."

Innovations: Whom is this book targeted to help?
Vlissides: 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 Design Patterns is, if not more so.

Innovations: What are your top ten choices for must-have technical books?
Vlissides: I really like everything from the "two Steves"—McConnell and Maguire. I especially recommend Code Complete (Microsoft Press, 1993) and Debugging the Development Process (Microsoft Press, 1994). It's too bad neither of these guys have said much about object-oriented programming. Another must-read is Tracy Kidder's Soul of a New Machine (Avon Books, 1995). It's a novel, not a technical book, and it doesn't focus on software; nevertheless, Kidder masterfully relates the gut-wrenching process of computer system development. It's a story that development people from all fields can learn from.

Then there are the popular object-oriented programming language reference books, since OOP is my bailiwick: Stroustrup's The C++ Programming Language, Third Edition (Addison-Wesley, 1997) and Arnold and Gosling's The Java Programming Language, Second Edition (Addison-Wesley, 1998). Sadly, both are harder to learn from than they should be. To compensate, C++ people ought to have a copy of Meyers' Effective C++, Second Edition (Addison-Wesley, 1998), and Java-ites should buy Horstmann and Cornell's Core Java 1.1: Fundamentals (Prentice Hall, 1997). Smalltalkers will find Beck's Smalltalk Best Practice Patterns (Prentice Hall, 1996) a godsend. And, with all due modesty, I can't avoid recommending Design Patterns (Addison-Wesley, 1995). Last but not least, everyone who has anything to do with software development should read Brooks' The Mythical Man-Month (Addison-Wesley, 1995). Its strong dose of reality will help you maintain a healthy perspective in the software development business.