he question John Vlissides is most asked about the landmark book Design Patterns: Elements of Reusable Object-Oriented Software that he and his colleagues wrote more than a decade ago is: when is the second edition due out? Readers clamoring for another edition of a book that has become a perennial bestseller for its publisher is not something Vlissides could have anticipated when the book first took shape.
The 1994 publication of Design Patterns was the culmination of the expertise and contributions of Vlissides, Erich Gamma, Richard Helm, and Ralph Johnson, four computer scientists (better known today as the Gang of Four) who Vlissides says brought together the best of both worlds: academic research and real-world experience:
- Vlissides was a consultant during grad school at Stanford before leaving for IBM Research.
- Gamma built ET++ (a UI toolkit and programming environment) in the late ’80s, and his dissertation described the patterns he discovered.
- Helm built programming tools at IBM Research (where he and Vlissides later teamed up).
- Johnson was involved with Smalltalk since graduate school and conducted work on design patterns as a professor at the University of Illinois.
He explained that practitioners had the experience building large systems yet were bound to strict project deadlines, while academics had more time to study large systems but had limited resources. The Gang’s ability to draw from the benefits of each helped vet design patterns from theoretical, academic research to practical solutions (because, as Vlissides puts it, “A pattern isn’t just an algorithm.”). “That’s where the real work lies,” he explained, “because the average academic has no clue what the practitioner’s problems are in the real world.”
GoF: Where Are They Now?
In his consulting experience during the late ’80s and early ’90s, Vlissides was confronted with practitioners’ problems at every project. He noticed clients using objects to solve the same kinds of problems over and over again. In those early days of object-oriented (OO) programming, most people were uncomfortable with the mechanics of object technology (polymorphism, encapsulation, etc.) and left it to their project leaders to think in those terms. Although smart, Vlissides says these project leaders also were dangerous: “They understood enough to make over-complex object solutions.”
Because the Gang had been developing OO systems since the mid-’80s?participating the annual Object-Oriented Programming Systems, Languages, and Applications (OOPSLA) conference throughout the late ’80s?they were in a position to formalize the most common object solutions, which could then be given to these project leaders. These so-called design patterns would keep them from reinventing the wheel and overcomplicating their solutions.
They recognized the design pattern’s two-pronged benefit as a vehicle for standardization. First, it would enable people to “reuse successful design successfully.” Vlissides says, “For a while I thought that was the main benefit.”
But there was a second benefit: design patterns engendered a standard vocabulary that enabled architects to discuss design at a higher level. Vlissides now believes this standard vocabulary is the most valuable benefit of design patterns and its main contribution to OO programming. Design patterns, he said, “enable a discourse that wasn’t possible previously.”
Motivated by these revolutionary ideas, the Gang began work on a paper to present their findings at the European Conference ? Object-Oriented Programming (ECOOP) ’93 [Kaiserslautern, Germany, July 26-30]. Richard and Erich revisited Erich?s original patterns, revising them heavily, dropping some, and adding others. But they remained far from complete. Then Vlissides fleshed out the Observer pattern and circulated it among the others. Gamma and he exchanged patterns, bouncing them back and forth with each other’s feedback and assessments, improving upon what the other had presented. “That to me was when we turned the corner,” said Vlissides.
By the time the ECOOP paper deadline arrived, the Gang had compiled more than 90 pages. “There was no way they were going to except that, so we narrowed it down,” Vlissides explained. Those extraneous pages didn’t have to go in the recycling bin though. The resulting paper was a set of patterns that sparked a strong enough reaction to earn them a publishing deal with Addison-Wesley for a full-fledged design patterns book, which they planned to debut 15 months later at the OOPSLA ’94 [Portland, Oregon, October 23-27] conference.
Vlissides took a hands-on approach to the publishing process, even doing all the drawings himself. He assumed the communication duties with their editor Kate Habib. “I wanted it to go out as efficiently as possible,” Vlissides said.
To assure efficiency, he employed the time-honored editorial tactic of sandbagging the deadline. “I asked Kate Habib, ‘what is the absolute drop-dead deadline for submitting copy in order to have the book published by OOPSLA ’94?'” he recalled. “June 1 was the answer. I kept that between myself and Kate and told the rest of the guys that was the publish date.”
This ensured that, unbeknownst to the other three authors, the Gang would have a completed draft a month ahead of schedule. It also ensured a hectic few weeks for all involved. “As the deadline drew nearer, they were performing more and more Herculean tasks,” Vlissides recounted. To meet the aggressive “deadline,” Johnson, a faculty member at the University of Illinois at Urbana-Champaign’s Computer Science Department, was dropping classes; Helm, then working for DMR, a consulting firm, was juggling project deadlines; and Gamma was burning the candle at both ends with his work at Taligent.
But they pulled it off and submitted a completed draft on June 1. That’s when Vlissides asked his colleagues a “hypothetical” question: “what if we had another month to fix what we wanted to fix?” He received an encouraging response and then disclosed his false deadline ploy. “Everyone was pleased to have the extra time to polish the draft,” he said. With the extra time, the Gang put the finishing touches on what became the first design patterns book.
At its debut during OOPSLA ’94, Vlissides recalls that the 100 copies Addison-Wesley had designated on site sold out within an hour. To meet the demand, the publisher had to divert a semi truck that was carrying more copies from Indiana to Oregon (Portland) during the show. By the end of the event, attendees had bought nearly 1,000 books. Slightly more than a decade later, Design Patterns is a perennial best seller for Addison-Wesley. The publisher claims more than 400,000 copies currently are in print.
So, When Is the Second Edition Coming?
When addressing the most frequently asked question regarding the book?when’s the second edition due out??Vlissides concedes that the idea hasn’t interested him much in the past, but design patterns have now reached a point in their evolution when the notion is intriguing.
Advancements in the technology for implementation are “what’s making it exciting again,” he says. Of the technologies he cited, which included Java and the three-tier architecture, Vlissides spoke most excitedly about automatic refactoring, particularly automating the refactoring to patterns.
Developers Talk Frankly About a Decade of Design Patterns
As for patterns themselves, he’s observed the myriad variants that have sprung up since the book was published (“some trivial, some not”). Vlissides states, “we’re in a position now with the Web to look at them from a higher level and consolidate?get some set of patterns that are mutually independent [within the three-dimensional matrix of implementation, problem, and solution]? patterns that cover as much space as possible without overlapping another pattern’s space.”
Although no plans are in the works for another edition as of yet, in his view, quality?not quantity?would be the ideal should the Gang reprise their book. “Any second edition is going to have more or less the same set of patterns and will cover the gist of what we’ve learned since ’94,” he explained. “If we try to be exhaustive, we’ll just end up being an index of countless patterns. The challenge is staying true to the original while incorporating what we’ve learned about OOP since the first [edition].”