Learning Design Patterns

A colleague of mine felt that Design Patterns are complicated and difficult to remember. He was wondering about how to learn Design Patterns in a way that would stick in his mind till the time comes to use them.

My motto for this has always been "Use it or Lose it."

When I first learned Design Patterns in my undergrad degree, I thought they were cool, but did not appreciate their full value and did not really get when to apply them and when not to. Naturally, due to not using them for a while (except for occasional use of singletons and observers,) I forgot many of them and was not able to detect the need for them when it arised.

Later when I was doing my graduate degree, I had the pleasure of relearning Design Patterns from a great instructor at DePaul University. That was when Design Patterns really clicked in my mind. A number of factors that contributed to that were the instructor's great emphasis on practical benefits to applying Design Patterns in real-world applications, my healthy-skepticism and asking of many questions, and the exercises that gave us the opportunity to apply Design Patterns whenever we learned them in order to better fulfill business requirements for maintainability and extensibility in real-world scenarios.

I was so excited about Design Patterns after taking that course that I started applying them at work on a new project and reaped great benefits from them. The use of Design Patterns like Decorator, Command, and Template Method helped create very flexible, maintainable, and extensible code for the ever-changing requirements that I had. The feeling I had whenever I received requirement changes and was able to incorporate them in practically no time due to the earlier application of patterns was absolutely exhilirating. From that point on, there was no turning back for me as I experienced first-hand the true benefits of Design Patterns on a real business application.

On later projects, I attempted to apply every Design Pattern that seemed to fit the problem at hand. That got me first-hand experience on many different Design Patterns and allowed me to truly learn when they provided value and when they did not. Additionally, more Design Patterns stuck in my mind due to having had first-hand experience of applying them.

Did I ever over-engineer? Of course. Do I regret applying the Design Patterns that caused that? Never. If you hold the pendulum in one side (lack of enough engineering) and never let it swing to the other side (over-engineering), you would never give it a chance to pass through the middle (just-enough engineering) and stabalize there eventually. In other words, If I had not tried new Design Patterns in the first place because of fear of over-engineering, I would not have realized their benefits later when I did successfully employ them in situations where they provided great value. Besides, that also helped stick them in my mind for future use.

So, what is the best way to learn Design Patterns and have them stick?

1. Study them with a genuine interest to deeply understand them and recognize when applying them would reap you benefits in real-world scenarios. My best recommendation for a book is Head-First Design Patterns because of its visual style, great humor, and deep tying of Design Patterns to Object-Oriented Design principles, which are the foundations on which Design Patterns were built. However, other great books are: Design Patterns Explained, Applying Patterns and UML, Refactoring to Patterns, and Design Patterns: Elements of Reusable Object-Oriented Design.


2. Early in the learning process, look for every opportunity to apply one of the Design Patterns. Keep a Design Patterns book next to you to refer to whenever you are designing new Object-Oriented code. That way, you can always check if a Design Pattern could help with the problem at hand, and thus get an opportunity to exercise it. In no time, you will develop a sense of smell for patterns and become able to detect the need for them instantly when it emerges without the need for a book.


3. Once you realize the benefits of a Design Pattern in a particular scenario, learn to focus in the future on recognizing when the Design Pattern is absolutely necessary and when it is just over-engineering. This is the stage of learning in which you start balancing the pendulum back in the happy middle. You don't want the pendulum stuck at either end after all.