Brian Foote on the 15th Anniversary of Design Patterns
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
InformIT: If you were at the 1994 OOPSLA in Portland where Design Patterns debuted, what are some of your recollections of that show and of the book at the show?
The brave men and women of the Addison-Wesley booth at OOPSLA '94 in Portland had no Internet connection, for those did not yet exist, at least in a form most people would recognize today. Cellphones were few. In October of 1994, cellphones were still largely an affectation for financiers. And they were caught in ... a stampede.
The only thing that seemed to back the horde was a wall of books. Not any book, but a particular newly-released book. They thought they'd come armed with plenty of them. But they were running out of them, fast, and, in desperation, exhaustion, exhilaration, and yes, disbelief, were trying to locate more...
While it wasn't quite Beatlemania, it was the closest thing to it that the likes of OOPLSA would ever see. It was a day that transformed the authors of a seeming arcane catalog of second-hand designs into software superheros. John Vlissides, Ralph Johnson, Richard Helm and Erich Gamma had been transmogrified into Gamma et al., The Gang of Four.
Even the name "Gang of Four" sounded revolutionary, or counter-revolutionary, or a tad subversive, depending on your view of Chinese history during 1970. It was at least what what we now call "disruptive."
Over time, even the moniker "Gang of Four" was abbreviated. Cognoscenti came to glibly refer to Design Patterns: Element of Reusable Object-Oriented Design as the "GoF" (rhymes with "cough") Book. The authors were simply "The GoF."
The Great OOPSLA 1994 Gang of Four Reading Frenzy was unprecedented. Before the show was over, more than 700 copies of the GoF Book had been sold. These would be the first of three nearly half-a-million copies that would be sold, in umpteen languages, over the next fifteen years. To set this number in perspective, bear in mind that some six million souls—about 1 in 1000 Earthlings—makes their living as a software developer.
InformIT: What was your initial reaction to the publication of Design Patterns?
I was a working with one of the authors of Design Patterns those days, Ralph Johnson, and the University of Illinois during the development of the manuscript for this book.
It was a highly collaborative, distributed effort, using email and newsgroups to exchange drafts and solicit what was probably an unprecedented degree of community feedback. This community building effort certainly contributed to both the quality of the resulting book, and to its subsequent heroes' welcome.
I was struck initially by how this effort broke all the rules of scholarship. What was new here was that nothing was new here. Academics were traditionally rewarded for publishing new, original ideas they had thought of themselves. The GoF book was full of old ideas that other people had thought of. It was a catalog filled with stuff that people working with objects, ahem, already knew.
It almost felt like they were cheating. It quickly became obvious that the GoF had slashed the Gordian Knot of Originality, in Computer Science, at least. Naming, describing, and cataloging indigenous accepted wisdom has become, well, not quite orthodox, but at least better accepted in CS than it was prior to the GoF book.
I was also amazed by the unexpected embrace that the idea of patterns as a literary form was to receive. Writing that diverged from the cold, sterile standards of academic journal writing of the time was regarded as ostentation, or as a fig-leaf meant to hide a presumed lack of rigor. The GoF book, and the patterns movement it spawned, helped bring a greater sense of clarity and concern for the reader into vogue in CS.
What I think struck me most was that the patterns book moved the focus back from programming languages and frameworks to the idioms and ideas that experienced programmers were able to express using these media.
InformIT: How has your opinion of the book changed over the last 15 years?
I think the thing that has surprised me the most about the GoF catalog is how well their initial cut on this part of the design space has held up.
We said at the time that we had no idea how many patterns describing the wisdom of the object masters at this level there would be. Dozens more? Hundreds?
Remarkably, this set of twenty-three patterns has held up surprisingly well. There may be another dozen or so patterns that have been subsequently discussed—some variations on patterns in the GoF catalog—that deserve to be mentioned in the same breath as the GoF patterns, but…
The real surprise is that the set that is there has held up so well. I’m reminded of the ancient constellation boundaries we use to map the heavens. Other lines than the established ones were drawn by other cultures, but the lines we know now, once established, the names we now use, resist attempts at revision.
Modern astronomers managed to add a few less mythologically colorful constellations to the ancient mix, but their efforts only underscored the beauty of the ones already set.
So it is with Design Patterns as well.
InformIT: How has Design Patterns changed your impressions about the way software is built?
The vision of reuse that we had in the object-oriented community in hindsight seems like a God that Failed. Just as the Space Shuttle never lived up to its promised reuse potential, libraries, frameworks, and components, while effective in as far as they went, never became foundations of routine software reuse that many had envisioned and hoped.
Instead, designs themselves, design ideas, patterns became the loci of reuse. We craft our ideas, by hand, into each new artifact we build.
We don’t assemble them like Lego blocks.
InformIT: How has Design Patterns impacted the last 15 years of development?
It’s fascinating to look at software written after the GoF book and compare it with software written prior to it. In shops that have been pattern infected, one is struck by the penetration of the GoF ideas, and the GoF vocabulary in the code itself.
That said, working programmers trying to cultivate more lucid, durable code often feel as if they are trying to fight off a lahar with garden tools. Mediocre code is still being produced at a prodigious rate, faster than it can be tamed. Patterns have shown us that better design is possible. But without a commitment to design integrity and sustainable development practices, these benefits can be washed away by burgeoning, unregulated growth and neglect.
The battle between the forces of “slash-and-burn” software agriculture and sustainability still rages, and the outcome remains uncertain.
InformIT: Have you been personally affected by the book? In other words, has it changed the way you think about software development or changed the way you develop software?
The GoF book made the world safer for the idea that software, code, could be better than some of the festering spaghetti code jungles that then, alas, as now, were all to often the product of teams that had never been exposed to the idea that there was any other way.
It reminded us that it was okay to believe that one’s programs could be a source of pride.
InformIT: What is your favorite Pattern (or least favorite Pattern) and why?
When I teach patterns, I’m fond, as the course comes to a close, of asking everyone in it both those questions. The answers I get are all over the map. When I’m done, I like to give an answer too. Mine have varied as well.
In hindsight, perhaps the most influential idea has been one that is not even explicitly in the catalog: the generalized notion of Factory. A Factory is an object that delivers an instance of some Product. This pattern exists in the broad penumbra that surrounds explicit GoF catalog entries such as Factory Method and Abstract Factory. By hiding the details of object creation by allowing Factories to produce products, the constraints and limitations of explicit object construction can be circumvented.
I also became fond of citing the humble Iterator pattern as a personal favorite. Its adoption by the Java community made this idea commonplace. Iterator keeps other objects from depending on how an object organizes its internal data, by supplying an Iterator instead. As such, I think its role in allowing objects to retain their integrity as a system evolves has been underappreciated.
But, I’ve developed a soft spot over the years for the notorious Visitor pattern. I’ve encountered classes where different students have named this pattern as their favorites, while others single it out for scorn.
Visitor may not be the most intricate design in the book, it has earned a reputation as being the hardest GoF “merit badge” to earn. I’ve found that no one, me included, has ever really understood it until they have built one, and that then the design idea was theirs, for good or ill, for life.