BT

Design Patterns: Magic or Myth?

Posted by David Budgen on Jan 04, 2014 |

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.

Acknowledgments

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.

References

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Facade pattern by Henrik Eriksson

The problem with patterns are even if using them you have to segment/implement the code in that particular way. The hard part is to understand where the code actually resides in the pattern. Also it's easy to mix the technical concept of the patterns and logical/structural concept of the pattern. Some patterns are more closer to each other but for example the facade pattern technical concept and logical concept are far apart and sometimes really hard to understand and particularly could cause severe damage to code structure.

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.

Ivory towers? by Steve Merrick

I wonder why you think that patterns should be usable by unskilled or uneducated practitioners? I wonder how many of your respondents were real software professionals, and how many were undergraduates and postgraduates? Have you heard of the problems psychologists (I think) are having with their results, having discovered that nearly all their subjects are WEIRD, and WEIRD people are not, as they thought, typical?

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 by Kaveh Shahbazian

Design Patterns ruined a big part of software development by wasting too much resource. To cut it down to the point: "Why the hell we should implement a Business Workflow engine when an if statement would do?". That's how design patterns work in majority of software industry (you know; those not-cool-kids without a blog that read garbage blog posts just once a quarter; those who actually do that for living not fun; those whom are not respected by anyone; The Dark Matter Developers - www.hanselman.com/blog/DarkMatterDevelopersTheU...). One innocent soul reads something "cool" and tries to fit it in every hole! And it's like the Holy Codex. It's like "The Word of Gods" (those smart, alien flavored, full of boiling self-steam, enthusiastic coffee consumers). No one accuse it (because it's Holy) and no one knows "when" it needs it (because you are always in need of holy things). In no text about Design Patterns there is enough context provided of the "when"! "when" means cost! No one needs a lamborghini to just peek up her/his parent to get them to the doctor (Maybe that would come in handy if you are about peeking up your girlfriend). It's not unnecessary ("unnecessary": that's another mistake when someone tries to reason against Design Patterns). It's "irrelevant"! When all you have is a team of 2 developers which should ship in 2 month then CQRS + Even Sourcing (Let alone messing around with Domain Objects, Data Objects, Business Objects, ...) is a one way ticket to hell! Design Patterns are not concrete rules. They are best practices achieved via studying many cases by many developers, spending many hours (perhaps ... years) in projects with "best assumptions for that particular problem" and this is where they suck. No design pattern is introduced based of how much effort or level of knowledge and experience it needs. They are not engineered! They are designed - at laboratory. At the end of the day one who ships and who shops are the real happy ones, not the "correct" guys. (OK, thanks for reading, I had to be dramatic to some extend to actually convey an atmosphere, not just a thought).

The words worked by Jaime Metcher

Firstly, kudos for doing this study. As you note, the lack of evidence in this area is pretty stark.

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: The words worked by Kevin InfoQ Mote

@Jaime Metcher: +1

Re: Design Patterns are Harmful by Luiz Esmiralha

Your understanding on how a pattern is "created" is flawed. Patterns are not built in labs, they are harvested from existing systems. That is why it is called a pattern and not a theory.

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 by Kaveh Shahbazian

"Your understanding on how a pattern is "created" is flawed." Absolutely agreed! Because what I've said is about what I "feel" about any novel idea in software engineering (not just design patterns) and how developers "use" these things to seem "cool" and "smart" (rather than solving the problem).

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).

That's where a "developer" must be able to "choose" his tools based on the current context (pretty much like 'this' in JavaScript!) not based on The Ultimate Perfect Design or any other target.

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 by Luiz Esmiralha

And yet another way to interpret the data is that we grossly underestimate the effort necessary to build systems.

I don't know about the study, I do know patterns help me! by Victor Grazi

I see a pattern in your study; the complex patterns (like Visitor; Memento) are the most troublesome. I would be interested to know how fluent the respondents were in the patterns they were rating.

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 by Kaveh Shahbazian

Well; that was my experience. And some real world statistics would help to see how "improvements" of software design and architecture applies to real cases. Meanwhile:

(www.joelonsoftware.com/articles/fog0000000018.html 2001)
(www.joelonsoftware.com/items/2009/09/23.html 2009)

“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 by Victor Grazi

>At the end of the day, ship the fucking thing!
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 by Faisal Waris

The GoF patterns were founded when OO was all the rage and mainstream languages du jour lacked expressiveness we can take for granted in now popular FP languages. (Back then ML and derivatives existed but few knew about them).

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

12 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT