The 1994 book Design Patterns: Elements of Reusable Object-Oriented Software [1] introduced many software developers to the concept of "a catalog of simple and succinct solutions to commonly occurring design problems" that nearly every object-oriented software developer knows of today as "design patterns [2]." Like most technical concepts (whether real or hype or somewhere in between), "design patterns" seemed to go through the normal stages of acceptance, rising rapidly from new idea to the prevalent way of thinking. As is always the case, this rapid rise in popularity led to backlash as design patterns were overused, abused, and otherwise used inappropriately [3]. Today, design patterns seem to have become accepted as a useful tool when used correctly, but are generally recognized as dangerous in the wrong hands.
I have generally avoided devoting an entire blog post to a discussion of the good, the bad, and the ugly of use of design patterns, but a fellow software developer recently made up an analogy related to his observations of the use and misuse of design patterns that motivated me to write this post. Andy [4] pointed out that there seems to be a tendency among some software developers to take an innocent and well-intentioned design pattern and turn it to evil [5], like turning a Mogwai [6] like Gizmo [7] into a Gremlin [8]. In this post, I look in more detail at why this is a particularly fitting movie-themed analogy for turning effective use of design patterns into misuse and abuse of design patterns.
The 1984 [9] movie Gremlins [10] begins with an inventor and father in Chinatown purchasing a Mogwai. Mr. Wing, the owner of the store does not want to sell the Mogwai to the inventor/father because "With Mogwai comes much responsibility." However, Mr. Wing's grandson sneakily sells Mogwai to the inventor/father while warning him of three important things to be aware of related to care of the Mogwai. These three things are:
The appropriate use of design patterns is not affected by bright light, water, or eating after midnight, but the effects of not taking care when applying design patterns can have effects similar to not taking care of Mogwai properly.
Rapidly Spawning Design Patterns
When Mogwai or Gremlins get wet, spontaneous reproduction of more Mogwai or Gremlins occurs. The effect can be very similar for developers with design patterns. It is easy for a developer new to design patterns (or a developer who is excited about a new design pattern that he or she has recently learned) to apply too many design patterns to the same problem. If design patterns are good, more of them must be better. It is similarly easily for developers to fall into the trap of applying the same favorite design pattern to too many different, diverse, and unrelated problems (Maslow's Hammer [11]).
Design Patterns Turned Evil
The Mogwai turned into mischievous Gremlins if they ate after midnight. Similarly, design patterns can be more evil than good if used inappropriately. A misapplied design pattern can obfuscate the intention of the code. Several design patterns used together can obscure the intent as well. Design patterns that are meant to facilitate better design can and often do lead to worse design when not used carefully. What is a design pattern in one situation might be an anti-pattern in a different situation.
One of the benefits of cataloging the common design principles as patterns is the ability to aid communication among developers and designers. However, design patterns can have the exact opposite effect (hindering understanding and communication) when misapplied or overused. I have also seen the case when a developer insists he or she is using a particular design pattern when he or she is really using a totally different design pattern or even an anti-pattern. In such cases, use of "design pattern" terminology also confuses rather than clarifying.
Well-Intentioned But Ill-Conceived
These problems most commonly arise when developers apply the design patterns because they believe they should [12] rather than because they truly understand their value in a particular situation. Rather than applying the same design pattern to every problem or shoe-horning a design pattern into a situation in which it does not fit well, the developer needs to understand the advantages and objectives of different design patterns, along with trade-offs associated with the design patterns, to make an informed decision about application of design patterns.
Effective Use of Design Patterns
It seems to me that the best use of design patterns occurs when a developer applies them naturally based on experience when need is observed rather than forcing their use. After all, when the Gang of Four [13] compiled their book on design patterns, they were cataloging existing design patterns that developers had been using already. Indeed, some of the patterns covered in their book became so popular that they were incorporated into Java language syntax and into other newer languages. For example, Java provided the interface [14] (which aids many of the design patterns covered in the original design patterns book) and newer languages such as Scala [15] and Groovy [16] have added their own pattern implementations.
Use of Design Patterns: Gizmo or Gremlin?
When used properly, design patterns are attractive and desirable just as Gizmo the Mogwai is an desirable pet. However, when used inappropriately or applied without appropriate care and consideration, design patterns can turn into Gremlins, wreaking havoc on one's code base and hindering the ability to understand and maintain one's design. Note that the design patterns themselves are not necessarily the problem, but rather the people entrusted with proper use of design patterns determine whether they maintain desirable like Gizmo are undesirable like the Gremlins.
Original posting available at http://marxsoftware.blogspot.com/ [17] (Inspired by Actual Events)
Links:
[1] http://www.pearsonhighered.com/pearsonhigheredus/educator/product/products_detail.page?isbn=0201633612
[2] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
[3] http://stackoverflow.com/questions/466365/when-are-design-patterns-the-problem-instead-of-the-solution
[4] http://www.linkedin.com/in/awestmey
[5] http://en.wikipedia.org/wiki/Mogwai_(Chinese_culture)
[6] http://entertainment.howstuffworks.com/mogwai-gremlins.htm
[7] http://gremlins.wikia.com/wiki/Gizmo
[8] http://en.wikipedia.org/wiki/Gremlins
[9] http://www.imdb.com/year/1984/
[10] http://www.imdb.com/title/tt0087363/
[11] http://marxsoftware.blogspot.com/2008/01/good-bad-and-ugly-of-software.html
[12] http://marxsoftware.blogspot.com/2009/08/software-development-bumper-sticker.html
[13] http://geekswithblogs.net/subodhnpushpak/archive/2009/09/18/the-23-gang-of-four-design-patterns-.-revisited.aspx
[14] http://docs.oracle.com/javase/tutorial/java/concepts/interface.html
[15] http://www.slideshare.net/remeniuk/effective-scala-programming-patterns
[16] http://groovy.codehaus.org/Design Patterns with Groovy
[17] http://marxsoftware.blogspot.com/