Steve Vinoski on the 15th Anniversary of Design Patterns
Steve Vinoski was one of the original reviewers of Design Patterns and is the co-author, along with Michi Henning, of Advanced CORBA® Programming with C++.
The following quote from Steve appears on the back cover of Design Patterns: "Design Patterns leaves the debates about code reuse behind and shows the real key to software reuse: reusable design. You'll find yourself applying and reusing these patterns in your own designs in no time."
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The publication of Design Patterns marked a fundamental turning point in software development, specifically a shift from focusing on how particular algorithms were best implemented in particular languages to a focus on how to best solve particular software problems within specific contexts. It wasn't an overnight switch, since by the time the book was published the software patterns movement had already existed for several years, but the publication of the book clearly asserted that patterns had indeed arrived.
As an industrial software developer who had the great fortune of being a reviewer of the original Design Patterns manuscript before it was published, I remember realizing as I read the draft that the book had a huge potential to fundamentally change software development. As the time for publication neared, Addison-Wesley asked my permission to quote me on the back cover of the book, so I asked my employer at the time if I could use them as my affiliation in my quote. They refused, saying they did not want their name used to help sell the book. Understandable, perhaps, but I remember thinking to myself as I submitted my quote, sans employer, that they didn't realize they had just passed on a rare opportunity to have their name on the back cover of what was sure to be an enormous success.
When reading those initial drafts I was amazed by the pragmatic abstractions that patterns could so easily describe. For the first time developers could discuss whole chunks of code not as sets of algorithms or language-specific constructs or loops or conditionals, but rather by succinct pattern names, such as Visitor or Flyweight, that conveyed pages worth of implementation details, assumptions, limitations, and potential applicability in just a word or two. Considering the fact that one of the most vital aspects of software development is successful communication between team members, this was quite a significant development, since it let developers communicate at noticeably higher and improved levels of abstraction and conciseness.
Initially my favorite pattern was Visitor. I did a lot of compiler work back then, and upon finishing my review of the manuscript I immediately reworked my code to implement Visitor, and it was well worth the effort. My compiler became more flexible, much easier to augment and maintain, and easier for my teammates to understand. But my all-time favorite pattern is Chain of Responsibility because it fits so well with the distributed systems and middleware work I've been involved in over the past couple decades. I've successfully used it in a number of production systems. Like many patterns, Chain of Responsibility seems obvious when you first hear about it, yet I've seen far too many distributed systems over the years whose brittleness and inflexibility could have been avoided had their designers employed this pattern.
Patterns in general and Design Patterns in particular have strongly influenced software development, but anything with such impact typically extends well beyond its initial target, making us consider it in other contexts and forcing us to consider its limitations. In this decade we've seen a growing interest in functional programming (FP) languages like Erlang, Haskell, Scala, and Clojure, and several prominent long-time functional programmers have publicly stated that the patterns that Design Patterns describes aren't really necessary for FP. As someone who made the switch from OOP to FP, I agree with them. Design Patterns focuses on OOP: its patterns are best suited for OO languages, and they're not well suited for FP languages. Furthermore, patterns have existed for a long time in FP, and most of the time they're just part of the language.
Yes, patterns have limitations, but this fact shouldn't come as a shock. After all, Design Patterns taught us that knowing the limitations and applicability of any given pattern is part and parcel of what patterns are all about. Knowing those patterns means we know not only when to use them, but also when not to use them. The fact that we as an industry in 2009 inherently know this and readily accept the fact that the patterns that Erich, Richard, Ralph, and John so elegantly described in 1994 have practical restrictions and limitations—that they're not a panacea—is perhaps the most important message of their book and is a clear validation of its profound and widespread positive impact on software development.