Don’t Misuse Design Patterns!
I can tell you for sure that at least 70% of programmers who start reading about software design patterns get really excited and try to find a place in their code to apply a pattern! I’ve seen programmers who even consider themselves experts on object-oriented analysis and design just because they’ve used some design patterns. They assume that applying design patterns is equal to object-oriented analysis and design!
I read a great post on Slashdot where a clever developer demonstrates how a simple Hello World application can be turned into a disaster by over-applying design patterns. He argues:
These GoF patterns can make life hell for the maintenance developer or app framework user, where people turn it into a contest to see how many design patterns they can fit into a single project. The overall “Design Patterns” philosophy is really “how can I defer as many decisions as possible from compile time to run time?” This makes the code very flexible, but the flexibility is wasted when a consultant writes code using lots of patterns to puff up his ego and then leaves without leaving adequate comments or documentation.
Design patterns are predefined solutions for common software problems. Before applying a design pattern, you need to understand the problem you’re working on as well as the problem behind a design pattern. Are they really similar? Have you ever thought about why a design pattern is designed that way? I mean, have you ever wondered why software engineers came up with “that” particular solution to “that” particular problem? Why not a different solution
Software design patterns are often inspired by object-oriented analysis and design. But object-orientation is more than classes, inheritance and polymorphism. It’s a way of thinking. You need to think in objects. In my opinion, it takes years to really understand and master object-orientation and there is never an end to it. If you haven’t read the book Applying UML and Patterns, I highly recommend you to read it cover to cover, perhaps twice! It’s around 900 pages but is an eye-opener. It will change your perspective about object-orientation and software design forever.
So, I suggest you use design patterns ONLY if you have in-depth understanding of the “reason” why a given pattern solves a problem. Patterns come at a cost. Sometimes you may come up with a simpler solution for the particular problem you are working on. Simply adopting a design pattern just to demonstrate your knowledge of patterns is going to take you down the wrong path.
Many design patterns tend to separate what changes frequently from what doesn’t. They use abstractions to accomplish this. Now, that may not be the case with the problem you’re working on. Don’t predict changes without any evidence!
Real World Example
In one of the projects I worked on, I tried to model a notification system with the ability to send out messages via different channels such as SMS, email and pager. The reality was, that never happened, and email was eventually the final notification channel. And I’m pretty sure SMS and pager will never come into the picture! So, all the time I spent on using abstractions and design patterns was wasted. I could have simply created a class with one method to send out emails as notifications. There was no need to use abstract factory, strategy and other patterns in that problem.
A good way of thinking about predicting changes is the old saying, “Fool me once, shame on you. Fool me twice, shame on me.” If you see changes in part of the software you’re working on, then apply abstractions and design patterns to protect against changes of “that” type. Don’t apply them just anywhere! If you blindly apply abstractions everywhere, you’ll end up with too much complexity and you’ll shoot yourself in the foot. Robert Martin explains this in more detail in his great book, Agile Principles, Patterns and Practices.
