Over-patterning software design.

Ah! Design Patterns! Yes those seemingly magical concoctions of code that appear to solve all of the problems plaguing software design. So profound is the initial impact of design patterns, that the engineer begins to believe that he/she has finally found mythical scrolls of wisdom, bestowed upon him/her by divine beings, so much so that after reading through them every design problem can be automatically deconstructed into a set of familiar design patterns. Using them seems to solve every challenge software engineering has to offer — and the engineer begins to believe that all that is ever needed on his/her desk is a copy of those very patterns. Yes, there was a time when I have been guilty of the very same thing.

There is also the misconception that patterns are drop-in replacements to traditional software design practices. It’s tempting to approach a design problem with a pre-packaged solution that patterns seem to offer. “Oh, we have a Composite, that means we need a Visitor for collaboration. So let’s use a Visitor then.” That was easy, but what was missed was the overhead of designing something as a Visitor. No one asked the question why a Visitor was needed, or if  it was indeed needed. Often the only reason given for such design decisions is, “… because a design pattern says so.” That’s not what design patterns advocate at all. Excess use of design patterns while designing software, inadvertently leads to Over-engineering.

This contradicts the popular perception which is of the view that patterns were created to address most commonly occurring design problems. Yes that is true, and no I am not trying to be a design pattern heretic and declare that patterns are useless. Patterns are in fact very useful when applied correctly. It is true that most software designs can broken down into sub-designs which can be collectively solved using a combination of different design patterns. But just because they can be, doesn’t mean they have to be. A designer well versed in design pattern use can quickly find adaptable patterns for most design problems — and can probably get them to work together if he or she understands the modalities of pattern behavior.  There is a dichotomy here; design patterns lead to over-engineering — and they are useful!! What is it then?

The truth lies somewhere in-between. Most problems with “Over-patterning” begin when there is an overbearing urge on the part of a designer to adapt his/her design, and sometimes downright bend it to fit to a design pattern. Just because a pattern fits or solves a problem, doesn’t mean it has to be used. Loading a software design with patterns is a mistake. One must remember, patterns add cost, and by cost I mean engineering cost. Strange — an engineering solution adding an engineering cost? But, thats how it is with any engineering problem in any engineering domain. Ironically if you refer each pattern you will often see these costs clearly pointed out by the authors. Call them disadvantages, limitations, issues or whatever other name you come up with, but the reality is that these issues aren’t trivial. An oversight or a failure to understand the implications of these in the overall design of a software system is what leads to overly complex  or over-engineered solutions.

An excellent article to read with regards to this is Joshua Kerievsky’s Stop Over-engineering.

2 thoughts on “Over-patterning software design.

  1. I wouldn’t completely agree or disagree with using patterns as a starting point for software design. Sometimes it’s easier to think thatw ay. What’s wrong with someone approaching a problem with a set of solutions in mind? What you are doing is ultimately solving the problem, that’s the whole point anyway. Plus a lot of software engineers are familiar with DPs and it’s easier to explain and interact with them within a team.

    Having said that, there are some patterns like Singleton that re simply used far to often and in the process abused.

  2. You are mistaken. I never said that patterns are not to be used. I use the word “over-patterning” analogous to “over-engineering” where you stretch your design to fit to a pattern to make things compatible. Why?..just because a deign pattern theory mentions a solution to a problem that appears similar to the one you are addressing. That’s not how it should be. You must re-factor to patterns, ie. use them to make things less complicated and repetitive in your design, which ironically, is the antithesis of over-engineering.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.