Design Patterns: Magic or Myth?
This article first appeared in IEEE Software magazine and is brought to you by InfoQ & IEEE Computer Society.
My name is John Wellington Wells,
I’m a dealer in magic and spells,
In blessings and curses,
And ever-fill’d purses,
In prophecies, witches and knells!
—The Sorcerer, Gilbert and Sullivan, 1877
An important element of this early Gilbert and Sullivan comic opera was the portrayal of the sorcerer as a domestic salesman rather than some exotic and mysterious being. It was the wares that were exotic, not the dispenser.
Unfortunately, this is just what so many managers and software developers continue to seek—a set of “spells” that will magically ensure success. Design patterns can be seen as such a set of spells—apt to be promoted as a way to ensure that software systems will work and that someone who understands the concepts can expect to be able to maintain the systems effectively.
The Basis for Design Patterns
Of couse, there’s a sound basis for this idea. It’s normal for designers in any discipline to later reuse positive experiences, adapting designs to meet new goals as appropriate. The software design patterns community tends to cite Christopher Alexander’s ideas about patterns in architecture as their touchstone,1 but we can see similar use of this concept in the design of motor vehicles, clothing, public transportation systems, libraries, and so on. Some uses involve static forms, but others are processes, rather like software.
In their early work, Beth Adelson and Elliot Soloway observed experienced software designers identifying their intention to reuse partial designs by assigning labels to them in new design plans.2 Francoise Détienne characterized this behavior from a cognitive perspective as using schemas—that is, mental models that encapsulate different aspects of a designer’s experiences.3
So it’s maybe not surprising that software developers readily embraced this idea when the Gang of Four (GoF) disseminated it through their book, which cataloged 23 software design patterns.4 The book has become widely (and probably wrongly) seen as definitive, although the patterns community has also gone on to create and catalog many more patterns.
Indeed, this enthusiasm for pattern mining has tended to obscure some key questions that remain largely unanswered, such as
- the design process question: Do patterns form an effective way of exchanging design knowledge? and
- the design product question: Do patterns help us to create designs that are easier to understand and maintain?
Neither question seems to have received much consideration from design pattern enthusiasts. However, as often happens with software design, when we look at the available evidence, the answers to both questions are rather mixed. So, as with Gilbert and Sullivan’s sorcerer, applying the magic doesn’t always produce the intended results.
Figure 1. Mapping study and two follow-on surveys. The initial mapping study identified 611 papers about software design patterns through the end of 2009. The two follow-on surveys both extended and helped interpret the mapping study results.
A Set of Empirical Studies
What I describe here is largely derived from studies conducted over the past few years with one of my students at Durham University. Figure 1 summarizes the relationships between these studies, which consist of a mapping study, conducted to identify relevant empirical studies,5 and two surveys that followed.6,7 In conducting the mapping study, we identified 611 papers about software design patterns in the period ending in 2009. From these papers, we identified and analyzed 11 experimental studies (the only ones that had been conducted in over a decade of pattern use) and seven “observational” studies to help explain and interpret the findings. All of the studies used GoF patterns.
Next, we organized a survey of the 877 authors of the mapping study papers to find out more about their views of the GoF patterns. Of course, some author addresses were no longer valid, leaving 681 authors, but we augmented these by asking respondents to pass our invitation on to appropriate colleagues and also by sending it to members of a mail-list for people interested in patterns. This eventually produced 206 usable responses (more than we had expected), enabling us to create a profile of “usefulness” for the patterns. Finally, we conducted a follow-on survey with those 206 respondents to see if we could better understand the three patterns that produced particularly varied reactions. Of 46 respondents, 27 provided comments and experiences.
An obvious question is how solid a body of evidence this all forms? The mapping study involved a comprehensive search for primary studies, so we can conclude that its outcomes are fairly complete and unbiased, even if the empirical data isn’t very extensive. The surveys sampled three different respondent groups, although our analysis showed them to have generally similar education and experience profiles. In addition, because the largest group included people who had written about patterns, we might consider them to be not only knowledgeable about patterns but also more likely to favor the concept. This should add weight to any reservations they expressed.
What Did We Learn?
The experimental studies we analyzed for the mapping study were diverse in many ways, although two did claim to replicate others. In particular, only three patterns were studied in more than half the experiments we examined—namely, Composite, Observer, and Visitor. The different studies used a mix of participants, including advanced undergraduates, postgraduates, and practitioners—all with some degree of pattern experience, although calibrating the extent of this experience is difficult. When interpreted with the aid of the observational studies, we concluded the following:
- The use of Composite seemed to create few problems, although we noted that users needed to understand recursion.
- Likewise, the use of Observer seemed to create few problems beyond the risk of producing overly complicated designs.
- In contrast, the outcomes from studies using Visitor were more ambivalent. On the one hand, its complexity was seen as a barrier to effective use; on the other hand, when used well, Visitor might actually aid system maintenance.
We conducted our surveys as a way to more clearly indicate which patterns were considered useful under what circumstances (something difficult to explore with an experiment). We asked respondents to assess the usefulness of all 23 of the GoF patterns (with the alternative of stating that a pattern wasn’t one familiar to them). Then we asked them to identify up to three patterns that they considered really useful and, in contrast, up to three that they considered of no value.
With few reservations, the Observer and Composite patterns were the top two choices in this ranking process, reinforcing the mapping study results. Also as with the mapping study, results related to the Visitor pattern were mixed. There was also a group of patterns considered of little real use: Flyweight, Interpreter, Prototype, and Memento, with the last receiving no positive “votes” at all. A few patterns, such as Chain of Responsibility, were noted as being useful only for specialized purposes.
Like Visitor, the Façade and Singleton pattern votes were ambivalent. Neither pattern was studied in other than one of the inputs to the mapping study. We conducted the second survey to clarify what characteristics of these three patterns caused such divergent views. The reasons turned out to be rather different for each one:
- Visitor was seen as useful only for limited purposes, and there was concern that its use could easily lead to implementation constraints and problems.
- Singleton was also seen as having only specialized purposes—but the expressed concerns tended to focus on its alternative role as a means of storing global variables within object-oriented systems. Some respondents viewed this as a useful facility; others felt (strongly) that it conflicted with the object-oriented model.
- Façade proved to be much less controversial than the other two, but some respondents were concerned about the way it could constrain system maintenance.
So, even though many respondents valued all three patterns, there was a strong sense that this approval was quite strongly conditional in nature.
So, How Far Does the “Magic” Work?
Perhaps inevitably, the evidence we can offer about the use of design patterns shows them to be part magic with a good stiffening of myth. Table 1 summarizes the seven patterns for which one or both forms of empirical study provide a useful contribution to the evidence.
With some caveats, the table shows that the Observer and Composite patterns are generally well-supported by experimental data and experience. Similarly, it suggests that the Visitor pattern is supported well enough for use with some caution. Beyond that, experimental evidence is thin, although our survey data of experience gives generally good support to Abstract Factory, Façade, Factory Method, and Iterator. The evidence suggested practicing something more than caution in the use of Flyweight, Interpreter, Memento, and Prototype. Otherwise (and avoiding the issues with Singleton), we have only very limited systematic data.
So, how well can we answer the two general questions regarding the effectiveness of design patterns posed earlier?
- In terms of supporting the exchange of design knowledge, patterns probably are effective in the hands of experienced users, but our combined studies suggest that the learning curve involves potential hazards (for an illustration of this point, see the report from Peter Wendorff8).
- In terms of helping to create products whose designs are easier to understand and maintain, the question remains unanswered by the data available to us. Most of the experimental studies analyzed in our mapping study involved participants who performed tasks related to maintenance, but they provided little, if any, support for the benefits of using patterns.
Many users believe in the effectiveness of patterns and offer some examples to support their views. However, like the sorcerer’s magic, the use of design patterns can generate unwanted effects, especially during a designer’s apprenticeship (a particular problem Wendorff identified8), and clearly, the effective use of patterns requires much more than a catalog, however good it might be.
(Click on the image to enlarge it)
* Table elements shaded in green indicate a lack of material that could be aggregated.
**Eleven experimental studies and seven experience reports.
† Total positive votes is 389; total negative votes is 113.
Much of this work was conducted in collaboration with Cheng Zhang as part of his PhD study. I am also grateful to the School of Engineering and Computing Sciences, Durham University, for providing support for the third follow-on study as well as to Sarah Drummond for her help with the qualitative analysis.
1C Alexander et al., A Pattern Language, Oxford Univ. Press, 1977.
2B. Adelson and E. Soloway, “The Role of Domain Experience in Software Design,” IEEE Trans. Software Eng., vol. 11, no. 11, 1985, pp. 1351–1360.
3F. Détienne, Software Design—Cognitive Aspects, Springer, 2002.
4E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
5C. Zhang and D. Budgen, “What Do We Know about the Effectiveness of Software Design Patterns?” IEEE Trans. Software Eng., vol. 38, no. 5, 2012, pp. 1213–1231.
6C. Zhang and D. Budgen, “A Survey of Experienced User Perceptions about Software Design Patterns,” Information & Software Technology, 2012, in press.
7C. Zhang, D. Budgen, and S. Drummond, “Using a Follow-on Survey to Investigate Why Use of the Visitor, Singleton, and Façade Patterns Is Controversial,” Proc. 6th Int’l Symp. Empirical Software Eng. and Measurement (ESEM 12), ACM, 2012, pp. 79–88.
8P. Wendorff, “Assessment of Design Patterns during Software Reengineering: Lessons Learned from a Large Commercial Project,”Proc. 5th European Conf. Software Maintenance and Reengineering (CSMR 01), IEEE CS, 2001, pp. 77–84.
About the Author
David Budgen is chair of software engineering in Durham University’s School of Engineering and Computing. His research interests include software design and evidence-based software engineering. Budgen received his PhD in theoretical physics from Durham University. Contact him here.
This article first appeared in IEEE Software magazine. IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.
I think the facade pattern is actually used more than you think particularly in a object oriented programming language but is also the most misunderstood.
Also there is no magical or mythical concepts to these patterns, it's just no way of actually verify that your code is actually structured so if it is a pattern or not. Of course there are language specific ways of "creating" these but any non trivial code base distorts these patterns.
This PhD, the highest academic qualification we have, seems to be based on a misunderstanding by someone who is not a software professional of what software patterns are, and what they are for. They are neither magic nor myth. They are a way for software professionals to label and discuss generalised problems that have been encountered a number of times. They are not an educational tool, nor do they confer the expertise necessary to understand them or to use them.
Design Patterns are Harmful
The words worked
To me the proof of the design pattern concept is the fact that you were able to conduct the study in the way you describe, have the conversations, write up the results, write this article, and have it understood. That is, design patterns are a communication tool, so the fact that your audience understands what you mean when you say "Visitor" (and may even nod knowingly when you comment about the complexity thereof) is a powerful thing.
Whether any invidual pattern is useful is a fascinating but secondary topic. Remember that capturing anti-patterns is just as useful as writing patterns. Even if you had concluded that every one of the GoF patterns is to be avoided, the fact that you are able to say that so succinctly demonstrates the success of the patterns concept.
Re: Design Patterns are Harmful
Given the number of badly-engineered and chaotically-designed systems (some maybe delivered by 2 guys in 2 months) I have seen in the past 15 years, I welcome the thoughtful application of proven solutions to recurring problems.
Re: Design Patterns are Harmful
I can now rethink myself this way: One thing that (almost) always is left out is "requirements". Requirements affects the design (AND quality) of the software - it's NOT the other way. Best practices should be taught in the context of requirements; not in the context of the software itself. Missing the "context" is harmful (Remember the Context, Remember the Context, ...).
I am not saying "Software Engineering" is really an engineering order - which is nearly enough, not. We rather grow software than building it. Yet there is a misconception here (and it's not anybody's fault): Software (the code) vs Software (just at the moment when it's running). These are two different things. First one is the material; second one is the product. What make these two different is their different "state". And the path from code to product passes over the land of requirements (context).
I would like very much to see how these observations of James P. Lewis of 2001 have changed 13 years later (2014) (source: www.lewisinstitute.com/_siteFiles/downloads/7.pdf):
"Studies have found that we spend over 250 billion dollars a year on software projects in the U. S., and that only 17 percent of those projects are finished on time, on budget, at acceptable performance levels, and at full scope. Fully 50 percent of them miss these targets they are late, overspent, have reduced features and reduced functionality. What is appalling is that the remaining 33 percent are canceled. This means that about 80 billion dollars a year is flushed down the drain because of failed
projects. Another way to interpret the data is to say that 83 percent of all software projects get into trouble."
Re: Design Patterns are Harmful
I don't know about the study, I do know patterns help me!
I personally find the most important pattern to be MVC, and I think that even in non visual application, the separation between data and functionality it promotes is valuable and produces good, maintainable, clean code. Visitor and Interpreter use-cases are less common, and the GoF explanations were complex. Seeing those in the book Head First Design Patterns or better, in Dr. Heinz Kabutz's design patterns classes, clarifies those greatly and illustrates their value. Visitor simplifies parsing so cleanly that it would be hard to do without it.
The communication and visualization provided by patterns, as well as the ability to refer to a catalog of precanned solutions, is invaluable.
Of course using a pattern instead of an if statement is overkill. Patterns are designed to provide a solution when solutions are hard to come by; not as a panacea for replacing every common idiom! But then that's a problem with the developer, not the design pattern!
Re: Design Patterns are Harmful
“Yeah,” he says, “At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”
Note: However I do believe the best outcome I could with for, is a more fundamental change in tool-set (like actual, real-world, not-fancy tools to make side-effects composable at language level or tools to analyze a code-base and look for garbage generators).
Re: Design Patterns are Harmful
I couldn't disagree more! The pundits always underscore that maintenance costs four to ten times the cost of the original code.
If rewriting the code to be cleaner and prettier can reduce the maintenace cost, then that is a positive contribution
Many of the 'patterns' are just idioms in functional languages
I remember when the GoF book first came out I religiously memorized all the patterns. And I have to say that they helped me write better code - although I only remember explicitly implementing the Interpreter pattern.
In typed functional languages - Haskell, ML-family (including F#), Scala, etc. - you can solve the same problems using just the base language. For example, Composite / Visitor / Interpreter can be addressed with Algebraic Data Types and pattern matching;
Iterator is just lazy sequences.
There has been cross-pollination of ideas:
- Observer and dependency injection (Factory [Method]) are ideas that hybrid FP-OO languages have adopted from earlier OO lanugages. The notion of Observer however has been generalized to operations over multiple (conjoint) event streams (Reactive and async).
- Map-reduce is a functional idiom now adopted by OO frameworks such as Hadoop
And there are new paradigms; Async is a new (monadic) paradigm which can't effectively be addressed as a pattern in mainstream OO languages (Note: C# async required a change to the language).
So the point of all this that we should move beyond GoF patterns and start to embrace new FP-OO languages and broaden our horizon.