Design Patterns CD : Elements of Reusable Object-Oriented Software
by Erich Gamma, et al

Our Price: $29.95

Usually ships in 2-3 days

Amazon.com Interview: John Vlissides

Amazon.com interviews John Vlissides, one of the core-four authors of the outstanding Design Patterns.

Amazon.com named the CD-ROM version of Design Patterns the best object-oriented programming book of 1998. We talk with coauthor John Vlissides about the Unified Modeling Language (UML), the patterns movement, and future methodologies looming around the corner.

Amazon.com: What's a good one- or two-sentence definition of a pattern for our readers?

John Vlissides: Ah, the eternal question! People have been tussling over a definition for years. Here's yet another try on this occasion:

"A pattern names and describes a recurring problem and a recurring solution to that problem. A pattern also teaches the rationale behind the solution and its trade-offs, enabling you to tailor the solution to your needs."

Notice that this definition doesn't limit the term to object-oriented programming [OOP] or even to computer technology in general--a pattern can capture any expertise.

Amazon.com: Your very important design patterns books gave a real boost to the patterns movement. Can you comment on more-recent pattern research?

Vlissides: I am routinely amazed by the patterns people write. There are now published patterns in nearly every area of software development, not to mention patterns in other fields (pedagogical patterns, for example). In fact, there are so many patterns that the complaint I hear most often these days is that it's too hard to find the "right one."

This is a real problem, but it's not the whole problem. That's because you can't apply patterns with great success until you've internalized them. It's rare to find a pattern that solves your problem in a snap. A pattern is not a pat answer; it teaches you about a problem and its solution, subject to certain constraints, which will vary. It's unlikely that a pattern will describe the solution to your problem with all the requisite precision and detail--not if your problem is difficult enough to warrant a pattern.

Instead, a nontrivial problem will require studying a pattern and learning how to bend it to your needs. You may discover in the process that the pattern isn't right for your problem after all, in which case you move on to the next pattern. Obviously, this process works best when you've internalized a critical mass of patterns in your domain of interest.

How do you acquire this critical mass? By reading--lots of reading! And that's why a global pattern index, while desirable, will not be a panacea. At best, it'll lead you to a body of patterns in your domain, but that's just the beginning. Only after you've read and studied and tried out several patterns will you start to gain the insights you need to solve tough problems. It won't be the simple look-up of a pat answer some expect it to be.

Amazon.com: I know you outline some of this in Pattern Hatching: Design Patterns Applied, but can you comment on the process of deciding which 23 original patterns made the cut? Also, what was it like to collaborate on this book, when, I gather, the four of you were more or less widely dispersed geographically?

Vlissides: The process was pretty simple, really. We rejected patterns that didn't have enough known uses and ones that didn't gel in time. We also avoided large patterns that could be broken down into simpler ones. For example, we didn't present Smalltalk Model-View-Controller [MVC] as a pattern because it is made up largely of smaller patterns we already had. Granted, there's more to MVC than just Composite-plus-Strategy-plus-Observer. But we didn't want to cover it exhaustively while more-basic patterns went begging.

Picking patterns wasn't the only process we had to work out, of course. Four-way collaborations aren't easy to manage, especially when you're trying to write a book together. It didn't help that the four of us were scattered about the continent during most of the book's development--no two of us were within 500 miles of each other except at the very beginning, when Richard and I both worked at IBM Research in New York. (He moved to Montreal after less than a year of working with me. Can't say as I blame him.)

The four of us met only two or three times, at conferences. We relied heavily on the Internet and e-mail. Being dispersed even had some advantages; we were forced to be thoughtful and crisp in our (sometimes heated) discussions, and we ended up producing an audit trail of e-mail that continues to be useful to this day. There were occasions when being spread over three time zones actually helped, by pipelining the effort: people in later time zones could pick up work on an unresolved issue after their more easterly colleagues had conked out. Many a time I would read my morning mail to learn that a solution got worked out as I slept.

Amazon.com: How does the growing adoption of UML help developers use patterns? Also, do you see modeling tools getting pattern-smart--i.e., being able to use patterns automatically?

Vlissides: UML is a big advance because, true to its name, it unifies the Babel of design notations and gives people a common diagrammatic language. While I don't think it's the last word (what ever is?), it plants a pivotal stake in the ground. UML is a help wherever people are talking and writing about software development, and pattern reading and writing are no exceptions.

As for UML's benefits in design automation, there's no doubt that drawing tools for UML can be a great aid in getting your designs across. Whether UML tools can incorporate patterns to comparably great benefit remains to be seen. As I mention in Pattern Hatching, my own foray into pattern-based tools taught me that the benefits of using patterns just as they are, as "food for the brain, not fodder for a tool," are hard to beat.

Amazon.com: One advantage to idioms and patterns is that they are fairly discrete design concepts. (Designers can use patterns regardless of their choice of software engineering methodology.) Do you see this methodological flexibility as an advantage to the future of patterns?

Vlissides: Advantage compared to what? Flexibility is one of the great strengths of patterns, but it's incumbent on the reader to make it happen. When it does, you get a degree of flexibility few other tools and techniques of software development can approach. Flexibility can only broaden the relevance and impact of patterns.

It's only part of their appeal, however. People like patterns because they capture expertise. They provide a vocabulary of design and targets for redesign. They can corroborate design approaches you're uncertain of. Et cetera.

Amazon.com: Any plans for a Design Patterns, Second Edition (or any other books in the works)?

Vlissides: Sure. As editor of Addison-Wesley's Software Patterns Series, it's my duty to keep the pipe full of good patterns books. The next one you'll see is probably Pattern Languages of Program Design 4, edited by Neil Harrison, Brian Foote, and Hans Rohnert. There's also a steady stream of pattern books from other publishers.

As for books from the Gang of Four proper, a second edition of Design Patterns is a no-brainer. But we have no desire to rush a second edition to market. Only when we have a critical mass of value-add over the original will we announce that a second edition is imminent--which isn't the case right now (late 1998).

Amazon.com: Obviously, patterns and software engineering will work with any object-oriented programming language [OOPL], but do you see any advantages to Java as an OOPL vs. Smalltalk or C++?

Vlissides: Personally, I'm doing most of my programming in Java these days. I believe it's superior to both C++ and Smalltalk for what I do, all things considered, although Smalltalk and its environments still have a certain appeal that nothing else quite matches. And yet there's no be-all and end-all language. Smalltalk is still great for edge-of-the-envelope tinkering, and I wouldn't do an operating system kernel in anything but C++--but I hope things don't come to that!

Looking to the future, I sense that one of the next great frontiers in OOP lies in mechanisms for better separation of concerns--like what Aspect-Oriented Programming (http://www.parc.xerox.com/spl/projects/aop/) promises--and mechanisms for integrating code that was developed independently, the goal of both Subject-Oriented Programming (http://www.research.ibm.com/sop/) and Binary Component Adaptation (http://www.cs.ucsb.edu/oocsb/papers/ecoop98.html).

Amazon.com: Most surveys I've seen still show that formal software engineering practices are not widely adopted. Why is this? Can you comment on future trends? (For instance, how do patterns/UML help the move to more-rigorous software engineering practices?)

Vlissides: Formal methodologies have been ignored because most suffer from some combination of irrelevance, impracticality, and oppressiveness. Methods produced by bureaucracies or academics are most susceptible to these ills and so are least likely to succeed.

A methodology survives because it is used, and the only ones I can see being used are those that are but a thin veneer over real best practices, those that do little more than institutionalize what has worked in the past. I don't know of many methods like that. UML is one small example of a relevant formalism. And it is the product of industry experience--an effort that has consolidated good ideas from lots of people over many years. Patterns do likewise.

Software development will become an engineering discipline because it evolves into one, not by fiat or academic contrivance.