Design PatternsMagic or Myth?

Software Developers are seeking “magical spells” that will ensure success.

Design Patterns are often seen as the exactly such a set of spells.

Magic

It makes sense for designers to try and reuse positive experiences that they have had in the past.

It seems appropriate to adapt these designs to meet new goals where appropriate.

Driven by the Gang of Four or (GoF) who wrote a book with 23 software design patterns. This has become widely (and probably wrongly) seen as definitive.

Basis For Design Patterns

There are two main questions to answer:

Do patterns form an effect way of exchanging design knowledge?

Do patterns help us to create designs that are easier to understand and maintain?

Are They Effective?

611 papers about design patterns were identified and analyzed using 11 experimental studies and 7 observational studies that were done on pattern use.

A survey of the authors of the mapping study papers was done to find out more on their views of the GoF patterns. There were 206 usable responses, then a follow up study was done of the 206 respondents, which yielded 46 respondents who provided a variety of reactions.

Empirical Studies

Three Patterns In All Studies The use of Composite seemed to create few

problems, although we noted that users needed to under- stand 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 am- bivalent. On the one hand, its com- plexity was seen as a barrier to effective use; on the other hand, when used well, Visitor might actually aid system maintenance.

Patterns considered of little use, Flyweight, Interpreter, Prototype, and Memento,

Chain of Responsibility, was noted as being useful only for specialized purposes.

Ineffective Patterns

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.

Facade proved to be much less controversial than the other two, but some respondents were concerned about the way it could constrain system maintenance.

Patterns With Ambivalent Results

Answers

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.

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 effective- ness 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 and clearly, the effective use of patterns requires much more than a catalog, however good it might be.

Conclusion

David Budgen IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 38,

NO. 5, SEPTEMBER/OCTOBER 2012

References