On the 20th Anniversary of Design Patterns

Like this article? We recommend 

Bob Bogetti

How has Design Patterns affected you and your career?

Design patterns appeared about the same time as UML was unleashed, along with the growing popularity of object-oriented design in general, not to mention the popularity of C++. All of these elements combined to create a more recognized and significant role of software architect. This new role of software architect allowed for the growth and advancement of senior level programmers and designers. The architect now had the language of design patterns, use cases, scenarios, interaction diagrams, etc. This provided an exciting and challenging new environment for me and many others.

With lower level details out of the way, design patterns opened up another area for exploration, that being application specific domains from which we now have domain specific languages (DSL) and domain specific design patterns.

The combination of design patterns, software architecture, and application specific domains has provided me with a deep and diverse background along with a wealth of experience throughout my career.

How has it changed how you think about software development?

Design patterns allow me to think at a higher level of abstraction to conceptualize new ideas more quickly and test them against requirements. They also provide the capability to create much more complex architectures than previously possible using lower level techniques.

New architectures and designs that prior to design patterns were unthinkable or at least unmanageable can now be quickly prototyped and tested.

This new-found efficiency and faster turnaround time has allowed me to pursue many different application specific domains which would have not been possible without design patterns.

How do you use design patterns today?

I find the use of design patterns to be very beneficial for communicating ideas and concepts in both greenfield and brownfield projects. They allow discussions to occur at a higher level of abstraction without getting bogged down by lower level details.

They are very useful for not only for new designs and prototypes but also for system, component, and implementation level design reviews, allowing everyone to quickly assimilate the core design concepts.

I find this to be a refreshing change and dare I say even exhilarating at times.

Which patterns should be retired?

Just as patterns have evolved organically, I feel that all patterns will exist much longer than expected as legacy systems continue to operate. It will be more of a natural attrition than a planned retirement of specific patterns. Even then, it may not be a true retirement as much as a modification or evolutionary refinement.

Which new patterns should be added?

I think that new patterns will continue to emerge naturally as advanced technologies, hardware, and software platforms are introduced. These new patterns will be at all levels including implementation, component, and system levels. They will represent additional views and perspectives reflecting new performance, hardware and software requirements. New application specific domains, use cases, human machine interactions, etc. will most certainly cause the creation of new design patterns.

Grady Booch

Design patterns are one of those once-in-a-generation ideas. As I look across this history of software engineering, I would have to place the art and the science of patterns to be one of the more important developments of my generation. Every interesting system is full of patterns, and the GoF's book was the first to make these patterns manifest in our vocabulary. That work has greatly influenced what I do in software and systems architecture. That being said, I do have one disappointment, namely, the the practice of design patterns is not as widely a part of mainstream practice as it deserves. Many developers are familiar with the concepts, but not enough take the intellectual discipline to make is a daily part of their work. Still, I believe history will show that what the GoF began will live on to influence generations of systems.

Kyle Brown

I was first introduced to Design Patterns while I was working with Knowledge Systems Corporation, a Smalltalk consulting firm in Cary, NC where Ken Auer was one of our senior consultants. Ken had been invited to a meeting of a group organized by Grady Booch that met in Colorado to discuss some crazy new ideas that Ward Cunningham and Kent Beck had gotten into their heads about something they were calling "Software Patterns". Ken became excited about this new way of talking about software design and brought that enthusiasm back to the rest of us in Cary, where we started a reading group to review these new patterns, including some from a new book (for which we only had some early preprints) that Ralph Johnson was writing (along with some C++ guys we didn't know) called Design Patterns.

It took the group a while to get adjusted to those early patterns—first of all many of the examples were in C++, which was a language few of us spoke natively, being the Smalltalk bigots that we were. In fact, as we started working our way through the patterns, the most common comment was that "this would all be easier in Smalltalk and maybe you wouldn't need these patterns". This was, of course, not a good way to build a first impression of a new idea.

The revelation for me came a few months later when I finally had the first complete version of the printed book in my hand. My wife and I were driving from Raleigh to Atlanta for the Christmas holiday in 1995, and I took advantage of the long drive to start reading the book. At some point during that trip, it all clicked.  My wife became increasingly annoyed at me as I kept asking her if she wouldn't mind driving just a bit longer before we switched over. As she finally pulled into her parents' driveway six hours later I realized that (a) I needed to make sure I drove the way back and (b) that this book was really, really important.

What had clicked for me as I read through the book was that I realized I "had" most of those 23 patterns. Once I realized what the template solutions really represented, I was able to think back to earlier designs I had built, or watched others build, where each of those solutions had been used.  For me, that was the power of patterns—the ability to realize that a common solution can  be applied in many different areas, and that you can put a name to the thing that allows you to talk about that concept with others and then use that new concept as part of larger constructs. That concept has stayed with me ever since, and influenced everything about the way I view software.

In the excitement of the days that followed I then wrote my own first patterns (published in PLoPD2 as the Crossing Chasms pattern language that was one of the inspirations for Martin Fowler's Patterns of Enterprise Application Architecture) and also started thinking about examples of where I had seen the 23 design patterns in Smalltalk.  That meant that when Sherman Alpert reached out to the comp.lang.smalltalk newsgroup with a question about places where others had seen people use the 23 design patterns in Smalltalk that I was ready with my examples. This led both to my collaborating with Sherman (and my co-worker Bobby Woolf) on writing The Design Patterns Smalltalk Companion and also on a number of OOPSLA and Smalltalk conference presentations explaining where the patterns showed up inside the available commercial Smalltalk frameworks.

It was working on that book with Bobby and Sherman that set the "pattern" for the rest of my career. Based on my experiences there I was later able to collaborate with Martin as a reviewer PoEAA, and then as a co-author with Bobby, Martin and Gregor Hohpe on Enterprise Integration Patterns. I've also helped introduce patterns into IBM, including in the executable form that  is part of IBM PureApplication System. Since then, I've also written five more books, become a series editor for Pearson, and used that experience to help mentor many others through their first book writing experiences. 

But the most personally satisfying and cherished experience that I had while writing The Design Patterns Smalltalk Companion was that it allowed me to get to know the late John Vlissides, who represented the GoF as our series editor.  Over the next few years as I went to work for IBM, John became not only a cherished friend, but a mentor as well. His untimely death left a hole in many of our lives and in the patterns community as well. So in memory of John, and in honor of Ralph, Erich and Richard I want to say—great work, guys, and thanks for all the great things I've gotten from the book!

Rob Daigneau

It's hard to believe that it's been twenty years since the ground-breaking release of the "Gang of Four's" Design Patterns. A lot has changed in this time. The Internet and web have become ubiquitous, and many have shifted their attention to creating software for mobile and cloud platforms. In light of this, some have said that the GoF book is less relevant. Such arguments miss the importance of this landmark book. Not only did it successfully identify fundamental design solutions that are still relevant to today's crop of Object Oriented languages, it also established a paradigm for codifying, explaining, and evaluating design solutions for a number of problems encountered in software development. Indeed, Helm, Johnson, Vlissides, and Gamma influenced many to follow their impressive example, including myself. Thanks to them, many of us now have a "Sixth Sense" and can say, "I see patterns." Thanks guys.

Amr Elssamadisy

I write this on a Saturday in Beijing after having taught a 2-day class on design patterns to a group of diverse developers and architects. It has been a while since I taught this class and it was a refreshing treat to do so again as patterns don't seem to be "in" these days.

What was really great, that in these 2 days we did a deep dive on many patterns—both from GoF and others—and we were able to (a) have great design decisions about problem/solution pairs, and (b) work on REAL problems of today that the groups were having both creating new software and maintaining old.

In short, design patterns gave us a chance to look at multiple solutions to their problems, weigh their strengths and benefits, and choose one or more solutions that would be applicable to their situations.

How has Design Patterns affected you and your career?

I was in grad school when the GoF book came out, and I was studying OO design and analysis—I ate the book up—although I was secretly disappointed the diagrams were using the Rumbaugh notation instead of the Booch notation (yes, there was a day when we did not have one modeling language to rule them all).

After I graduated, I was so excited about this way of thinking that I took every chance to put a design pattern wherever I thought it would fit. I was very enthusiastic, and not unlike many young developers, well.... needed some experience.

Throughout my career I've collected and read many design patterns books—and I ate up different ways to approach problems. I frequently would just pick up a book, read just the context of a couple of patterns, and then put it down. Later, when encountering a problem in my code, or in a design discussion with my peers, I'd remember the pattern, pick up the book, and share the solution.

When agile development techniques came around, my knowledge of patterns was put in use when I chose to refactor code—the destination design was frequently a pattern that I became aware of.

Finally, I really love patterns—I love the problem/solution pair approach. I love that patterns are discovered—not created; that is that they are empirical in nature. They are a documentation of what many practitioners have done to solve a problem.

Which patterns should be retired and which new patterns should be added?

I'm an old fart. So I'm not sure any patterns should really be retired. I understand—and agree with—much of the criticism leveled at patterns—that they are often a limitation of the language, and in many languages, many patterns are not applicable. That's just fine with me. It is really good to know how things work—and more importantly HOW they work—even if they are embedded in the language.

As for new patterns....boy....I'd love patterns describing our current way of work—whether they are for mobile apps or web apps or anything else. I'd love to see testing methods put into pattern format (xUnit Test Patterns is a great start—but it is a monster book—maybe something published towards different specialties... with multiple examples). How about some patterns describing how NoSQL databases are used? Or a book on UI patterns—all of these frameworks out with MVC, MVP, MVMM, MV2... come on! What's the difference? What problems are we solving? And, most importantly, what are the trade-offs?

Richard Gabriel

Culture: The Ultimate Fallout from GoF

Technologists love technology. Software and design patterns are a soft form of technology, but a technology nevertheless. Patterns (for short) inherit from Christopher Alexander’s philosophy of care for the human side of technology, and we see it in the practices and social structures of the PLoP conferences—Pattern Languages of Programs. Let’s look at these.

Writers’ Workshops: Patterns are both ideas and literature; a pattern teaches a good solution to a (design) problem, arguing its value and mechanisms in natural language—that is, it’s not a diagram and a code snippet. At least, not just. A good pattern is well-argued; it’s pedagogically sound and compelling; it teaches design; it appeals to design thinking. PLoP was designed around the writers’ workshop, a formal critiquing technique used in MFA programs, writers’ conferences, and writing classes for many decades. A writers’ workshop at PLoP is a group of pattern authors and perhaps a small audience. Each paper is reviewed in turn for about an hour. A workshop leader or teacher directs discussion of the piece. The author is silent, listening as the group summarizes the work (often surprises pop up here), points out what works well, and suggests improvements. Authors learn how readers view the piece and how other authors think. Discussion points at the technical, the literary, the practical, and the pedagogical. In a writers’ workshop, each writer gains insights into the workings of their own work, and workshop members derive insight about the process of writing and how written work works. A writers’ workshop works this way: “We teach each other”; “I teach myself.” Mary Shaw once said, “it conveys twice the information in half the time.”

Games, Ceremonies, and Rituals: Games are scattered through each PLoP. From an opening (usually) Name Game to a closing Yarn Mandala Ceremony, PLoPs invite the notion and action of games to build a community for a short time for intense and intensely personal interactions. PLoPs are regional—US, Europe, Scandinavia, South America, Japan, India—and some have culturally significant games and ceremonies. At VikingPLoP, authors burn conference versions of their papers to clear the way for new ones. Games, ceremonies, and rituals form a community of trust.

Shepherds: Imagine academic insanity. Before the program committee of each PLoP judges the papers for acceptance, submissions are assigned shepherds from those who volunteer. A shepherd’s job is to review the paper, make suggestions for improvement, and to exercise this cycle two or three times. A shepherd is a personal mentor and editor. All this before the paper is even examined closely by the program committee. It takes a month or so. The reward for the authors is that, after acceptance, they enjoy yet another in-depth critique at the PLoP conference. The reward for the shepherds is that their gift eventually comes back around.

Shared Meals and Long Evenings: Academic conferences have banquets—sometimes. These of course are designed to bring all the attendees together. Critics of banquets argue that a banquet is a poor substitute for an evening at a bar with a small group. At most PLoPs, all meals are shared—three a day. PLoPs are small because nearly all attendees are authors of accepted papers. At PLoP 2014 there will be eleven shared meals, all served at the eclectic dining room at Allerton Park in Illinois. After the last meal of the day, the lounges and shared rooms are packed with groups and pairs talking and sharing patterns, code, and stories. These go late into the evening because Allerton Park also provides the sleeping rooms for the conference.

Gift Giving: Writers at PLoPs bring small gifts and present them to people whom they admire, wish to thank, or simply like. The gifts usually reflect something about their givers or where they come from. Look at all the characteristics I’ve outlined—it’s obvious that gift-giving is the heart of PLoP.

☆

Alexander teaches us that built structures serve human purposes, despite the depth of technology and science underlying them. Design bridges the human / technology strait. Programming is pretty tough, and schools teach only the most rudimentary parts of it. Experience and mentors do the heavy parts. Patterns coalesce design and coding knowledge­—technical and tacit—they are teaching tools. People writing patterns are giving the gift of their experience to others, a valuable gift because the cost of gaining experience is great. PLoP’s culture of gift giving falls out of this. People who write patterns are people who help others.

☆

GoF and PLoP share an anniversary—Autumn 1994. The GoF authors were among the founders of the Hillside Group and helped design PLoP. The PLoP culture thrived because GoF was a stupendous success. GoF’s success was amplified by the PLoP culture. GoF is the technological half of the patterns centaur and the PLoP culture is the social half. The PLoP culture is the first and best example of a scientific / technological community welcoming artistic techniques into its process. For this alone we must thank Erich, Richard, Ralph, and John.

David Heinemeier Hansson

The Design Patterns book was my original introduction to the idea of design patterns, and for that I’m ever grateful. It wasn’t so much the specific patterns, although many of them were and are useful and I employ them still, as the way of thinking about design patterns.

Matt Heusser

Without design patterns, we'd end up with the big ball of mud every time. Oh, don't get me wrong, we'd start out talking about clean code and responsibilities, and the designs looked nice on paper, but then came maintenance mode, when every fix could be done the hard way with a redesign, or the "easy" way with a new parameter added to the function and a new 'if' statement.

Three years later you'd have a ball of mud that screamed for rewrite. Except, of course, three years later you'd have another ball of mud.

Design patterns gave us a language to to refactor to and some reference examples. This turned out to be incredibly powerful. Oh, they've been abused, and there is some criticism, but the world seems to be splitting into those who can maintain code and those who can't—and one of the key indicators is the former group have read design patterns, or, increasingly, read something written by someone who was heavily influenced by design patterns.

Joshua Kerievsky

The Design Patterns book changed my life: it helped me become a better programmer, it introduced me to fellow practitioners in my local patterns study group, it introduced me to the software community’s most thoughtful and talented practitioners, authors and leaders and it helped me teach others about better software design. Few books in our industry have earned the status of literature, yet Design Patterns easily fits that category. I remain deeply grateful to Erich Gamma, Ralph Johnson, John Vlissides and Richard Helm for sharing their wisdom in what has become a classic book in our field.

Mary Lynn Manns

I was not working as a software developer when I was introduced to the Design Patterns book. So, I did not use the patterns in my work at that time. However, these patterns inspired the pedagogical patterns work that began at an OOPSLA conference in the late 1990s. I found myself in a bar with four university educators (from three different countries), discussing design patterns. This led us to to ponder whether "patterns" could be used to document successful practices in pedagogy. We studied the design patterns (and the work of Alexander) and decided to move forward with the pedagogical patterns project, which is still going strong with an ever-growing number of educators who are still writing pedagogical patterns today.

In addition, the design patterns work inspired me to attend a ChiliPLoP conference where I met Linda Rising. Design patterns sparked our thoughts about the possibility of using "patterns" to capture successful practices in introducing new ideas into organizations. With our first book, Fearless Change, ten years in print and still going strong, our second book, More Fearless Change, will be published in early 2015.

And, finally, a personal note about meeting John Vlissides. I rode in an airport van with him to a PLoP conference (at Allerton). I was young and quite inexperienced with patterns, and I was in awe that John was sitting there. I couldn't even think of the words to say to, wow, one of the Gang of Four. However, John may have sensed my nervousness—soon after the van left, he started asking me questions about my interest in patterns. I felt so privileged to have this time with John. I learned so much during that van ride and, even more importantly, he made me feel that my budding work in patterns could be valuable. I know that this experience was just what I needed at that time to give me the confidence and drive to continue writing and working with patterns to this day.

Michael Ogrinz

It’s incredible to think that it’s been 20 years since Design Patterns was first published. The fact that many of the patterns in the book have become native features of the languages and libraries that we use every day is a testament to this work’s influence. A generation of programmers can streamline their conversations with references to iterators, decorators, factories, etc. while focusing on broader issues—all because the “Gang of Four” authors recognized a set of recurring problems and solutions and undertook the rigorous effort to properly document them.

The patterns have strong roots in object-oriented programming and in some cases specific data structures. As languages and hardware continue to evolve, we will see some of the pattern definitions change to become even more general than they seemed two decades ago. The legacy of Design Patterns is that as old and new patterns occur, software engineers are ready to recognize them and (thanks to other revolutions including open source software) share these discoveries with their peers.

Dirk Riehle

Addison Wesley is going to celebrate the 20 year anniversary of the Design Patterns, a.k.a. Gang-of-Four, book. For this, they reached out to the community and asked for contributions. Here are the questions they asked, suggesting we ask (and answer) our own ones as well:

1. How has Design Patterns affected you and your career?
2. How has it changed how you think about software development?
3. Do you have specific recollections of the book's release?
4. How do you use design patterns today?
5. Which patterns should be retired?
6. Which new patterns should be added?

How has Design Patterns affected you and your career?

I was a lucky reviewer of the original book (you can find my name in the acknowledgements), and I am the translator of the German version. The Design Patterns book gave birth to the Pattern Language of Programming conference series, and I contributed at least one chapter to each of the five books that came out of the conferences. I organized EuroPLoP early on, and I got to meet many leading researchers and practitioners when other aspiring professionals were only looking. So, the book—and more so being given a chance to grow in its community—was a wonderful empowering experience that boosted my career in many ways. I'll be forever grateful to have received that opportunity. It isn't over by far. The book is still in use and going strong and will continue for the foreseeable future. As the translator of the German version, Addison-Wesley recently returned the copyright of the content (not the German title) to me, and I can use this content as I please. I will make it available on the web at http://musterwiki.de and we believe we have a realistic plan on how this could be a community-edited spam-robust wiki.

How has it changed how you think about software development?

When the book came out I had just finished my German diploma in computer science, which is something between a Bachelors and Masters degree. At the age of 25, I had had some software design experience but of course was far from being a seasoned professional. The book's content was a revelation and showed me a level of abstraction of how to think about software design that is hard to get to without guidance. By working with patterns, I slowly climbed to that level over the next years, eventually acquiring the ability to reason about and design software on the level of object collaborations and larger class structures that I'd consider an important ability of a professional software architect. My dissertation about object collaboration structures had strongly been informed by the Design Patterns book and is with me today still.

Do you have specific recollections of the book's release?

Ah, good ol' reminiscing. I had not got an advance copy but ran to the Addison-Wesley booth after the keynote as soon as the exhibitor's hall at OOPSLA '95 opened (or was it 1994?). I quickly got my autographs in the book from the gang of four that same day, if I remember correctly. The book sold out quickly. Lots of events and dinners hosted by Addison-Wesley and others followed over the next few years, as the patterns book market took form (and eventually dissolved into the agile methods movement).

How do you use design patterns today?

It is amazingly simple. Patterns have become a basic building block of my professional vocabulary. The vocabulary itself has diversified, domains and growing expertise have added to it, more variations of patterns entered it. The basics haven't changed. Patterns, like most languages, primarily serve informal communications like design discussions on a whiteboard. In addition, they are used in specification and documentation. I have never used them for code-generation.

Which design patterns should be retired? (In defense of Singleton)

Addison-Wesley asked the patterns community (or at least those who were there at the beginning) about their opinion.

For this very specific question, I expect everyone to say: Retire Singleton!

I beg to differ; for its time, Singleton was right. "Its time" mostly means single-threaded C++ code, as written by 3 of the 4 authors of the Design Patterns book. Today, many will argue that multi-threaded Java programs have made Singleton obsolete and even harmful. In my take at design patterns, that would be wrong. Singleton should not perish, it should simply be adapted to its time. Whatever thread-local information you may have, some of it will be global to that thread. How is that not a thread-specific singleton? Or, take a group of application servers acting as a group: How is the group communication protocol not to provide a global id that makes the group identifiable and provide some global state attached to it? This may not be your granddaddy's good ol' singleton, but a singleton it may be nevertheless.

This is also where pattern descriptions will pass (or fail) the test of time: Does the original description of Singleton allow for these variations or not? If not, it may have been too narrow a description. I'd assume then that specific usage examples, tied to the programming languages and systems and technologies of its time, dominated the description and the abstraction process "out of examples, timeless patterns" did not yet conclude.

Beyond Singleton, some may want to retire Visitor, mostly because we find functional programming concepts being added to programming languages more and more, and multiple dispatch (which Visitor is about) comes for free. I say: Simply be precise about the scope. Visitor is (kind of) fine for Java but in a different context may not be needed as a design pattern because it has been cast as a language feature.

Design pattern should evolve and there is nothing wrong with it. John would approve.

Linda Rising

Since 2013 saw the celebration of the 20th PLoP(R), the patterns conference, I guess it must be true that it's time to celebrate the book that has had a huge impact on software development, both conception and practice. For this anniversary, PLoP returned to Allerton Park, a 100-year-old Georgian-style mansion near Monticello, Illinois, USA, maintained by the University of Illinois at Urbana-Champaign. I was heartbroken to realize that my schedule did not allow me to attend. I miss Allerton. That was really where it all began for me. The setting was perfect for discussions, writers workshops, and games. It's where those of us who love patterns had a chance to toss about ideas and consider wonderful possibilities.

The publication of Design Patterns changed everything. Its success really forced us to think hard about what patterns were all about and what would be the "next" book or the "next" big patterns idea. However, I don't think there has been one. Design Patterns appeared on the stage, everyone got excited and bought a copy and many, many other lesser players followed. I don't think this is a bad thing. Patterns were embraced and have become a part of the way we think. We've all become pattern lovers. It's not just a handful of cognoscenti who gather at beautiful places to hold esoteric discussions. Patterns for the people!

The impact on software development is seen in how most people now know patterns—the ones in Design Patterns. I have done countless informal surveys of audiences around the world, and when I ask, "How many of you know what patterns are?" most participants raise a hand. When I ask for more explanation, I get the name of one of the the design patterns, for example, Observer or Mediator. I hardly hear anyone mention Christopher Alexander. When I ask if anyone is using patterns, listeners are confused. Of course, we are using them. Isn't everyone using them? Patterns have become mainstream. That's a lot of change in a short time. I think it's because developers are smart people and they want to do a good job and they saw these patterns and looked for ways to make it happen.

When I think of how patterns have impacted my life, I have to recall that before patterns, I was a techie, a designer. When I started working on patterns for introducing new ideas into organizations with Mary Lynn Manns, I gradually became a "people person" and woke up to see that it wasn't just good technical solutions that would save the day. Without understanding how to influence change, even the greatest ideas were likely to fail. Mary Lynn and I started working on Fearless Change 20 years ago. Ten years later, our book was published, but we never stopped learning about and growing the patterns. Here we are 20 years later, ready to produce a follow-on, More Fearless Change, that includes new patterns and "insights" on the original patterns. The journey never ends—as long as we are alive and have the energy to continue. We had to call a halt to the patterns in the new book but we have, in the background, a list of potential patterns and continue to have e-mail discussions on known uses.

My husband, Karl Rehmer, and I are also continuing to work on our collection of patterns for sustainable development—not software development, but development of human potential. We have become board members of Habitat for Humanity, which will enable us to see from the inside how a long-lived organization helps to improve the lives of others. I suspect we will be working on these patterns as long as we are able. We have published the initial collection: http://www.sustainabilitypatterns.info/Published_Papers.html.

Let me close my ramblings with my fondest pattern memory—meeting John Vlissides at OOPSLA. He had an idea for something he called "A Pattern Almanac," and he thought that I could be the implementer. I was so overwhelmed that he could believe that I could really pull of this massive project—documenting all the published patterns—over a thousand at the time. I signed on and never looked back. Regardless of what the Almanac did for the rest of the world, I know what it did for me. It gave me a chance to work with John and have the awesome experience of seeing how he worked, how he thought. He was unbelievably patient and kind and encouraged me every step of the way. I'll never forget him.

Thanks, John. And thanks to all the members of the patterns community. I love you all.

Alan Shalloway and Jim Trott

Design Patterns in an Agile World

After two decades of use, design patterns are as misunderstood as they were when they were first introduced. They are misunderstood by developers who naively force a design pattern—or what they understand a pattern to be—only a solution. They are misunderstood by agilists who think design patterns are a vestige of the Age of Big Design and should be abandoned. But like many truths in life, just because they are misunderstood by many does not mean they are not relevant. In fact, they are more important and more useful than ever and especially in an Agile world. They just need to be understood.

To understand design patterns requires understanding the thought process of patterns. Near the end of The Timeless Way of Building, the inspiration for design patterns in software, Christopher Alexander states that, “At this final stage the patterns are no longer important: the patterns have taught you to be receptive to what’s real.” In the world of software development, what is real is how you manage variation.

In their seminal work on design patterns, Ralph Johnson, John Vlissides, Richard Helm, and Erich Gamma (the “Gang of Four”), described the essence of design patterns as,

• Design to an object’s behavior
• Use delegation instead of inheritance to contain new behavior
• Find what varies, encapsulate it behind an abstraction (e.g., Interface) and delegate to it without the client object knowing which type of object it has

This advice still stands the test of time. In a nutshell, it means to hide variation so that client objects don’t have to change when a new behavior is required.

Prior to the widespread adoption of Agile, this was usually applied to variations that were present in the initial design. But as Agile came more and more to the forefront, its meaning has come to include variation over time. In other words, design patterns can be useful in hiding the variation of our understanding of a requirement over time, even if only one implementation is present at any one moment.

Design patterns therefore become one of the cornerstones of emergent design along with refactoring and test-driven development. By following the mantra of delegating to an abstraction that hides variation as it becomes necessary, designs can evolve while code quality stays high. Design patterns provide insights into the solutions that are evolving and they guide the refactorings required to achieve these solutions.  Design patterns become a thought process instead of a set of solutions.

A terrific resource that shows design patterns—and refactoring and TDD—in the context of emergent design is Essential Skills for the Agile Developer: A Guide to Better Programming and Design by Shalloway, Bain, Pugh, and Kolsky. For example, they identify and describe the following essential practices that spring directly from design patterns:

• Design to interfaces
• Programming by intention
• Define tests up front
• Interface oriented design
• Acceptance Test-Driven Development
• Prefer delegation and encapsulate what varies
• Separate use from construction
• Encapsulate that
• Commonality and Variability Analysis

Refactor to the Open-Closed Design patterns are still relevant today but the books that introduced them 20 years ago need to be updated. For example, the iconic book by Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software, is showing its age. It provides examples using languages such as SmallTalk and C++ which are not as widely used today. And it shows solution illustrations that use structures that were more idiomatic 20 years ago and not necessarily best solutions today, such as using linked lists instead of collections. But even if some of the details need to be updated, the essential thought processes are still solid. It is the wise developer who will listen and do the mapping to today’s contexts. And incorporate the thinking processes of design patterns into their practice.

Jason McC. Smith

Only a few books come to mind that have had as large an impact on the software industry as the Gang of Four’s Design Patterns. It stands in rarefied company, and launched a revolution in software design that continues to ripple out to this day into new areas. On a personal level, to say that it affected my career path would be a vast understatement.  As a budding graduate student with a decade of professional programming experience under his belt, the publication of Design Patterns was a revelation. It provided more than a cookbook of solutions, it laid the path to a new way of thinking about software: that software is comprised of conceptual building blocks, not just functional or syntactic ones; that the abstractions and design issues behind the scenes were at least as important to the end product quality as the functional aspects; that we could collaborate to form a community to share the ‘fuzzier’ knowledge in well formed ways and bring it out of the realm of technological wizards, and into the grasp of us mere mortals.

These ideas may seem commonplace now, but it is difficult to underscore exactly how groundbreaking these concepts were at the time. More years have passed now from the publication of Design Patterns than had passed between it’s publication and the introduction of the personal computer. Object-oriented programming was only just hitting the mainstream with the advent of C++ and Java, and best practices using these new approaches were thin. Design patterns were, and are, a way to capture and convey best practices of design in a way flexible enough to accommodate a range of problem domains and implementation languages. They fired up the mind and offered new shoulders of giants on which to stand. As a student looking for a meaty problem to sink my teeth into, the appeal was irresistible.

Within a year of the arrival of design patterns, I had a research plan to approach the design patterns literature from an analytical viewpoint, resulting in the System for Pattern Query and Recognition (SPQR), an automated tool for design pattern instance detection in source code in a language independent manner. Once I had taught a computer to decompose and recompose design patterns in a well-formed way, it seemed natural to do the same for developers.

This work led to the publication of Elemental Design Patterns by Addison-Wesley in 2012, and the freshly minted design patterns description, discernment, and diagramming specification from the Object Management Group: the Structured Patterns Metamodel Standard (SPMS). The former text is a bridge between the realms of automated computation and human understanding of software design, the latter specification is a structured system built on existing standards to allow our communities to collaborate more reliably and closely.

It is this kind of advancement that continues to occur, continues to grow, and continues to push innovations in how we plan, create, and maintain our software systems. Design Patterns lit a fire that burns to this day, and doesn’t appear to be extinguished any time soon.