Shivkumar C Muthukumar
 
Search this site

Last Updated: 25th Jul '09

Design Patterns

Design patterns is one of my favorite topics ever since I started programming in object-oriented languages. In fact for the first several months I discovered many of them independently and really enjoyed the process, without the slightest idea that they are known to people by various names.

Apart from applying design patterns, I also enjoy reading, writing and discussing about design patterns. For the past couple of years I have also been teaching design patterns a whole lot. I thank Trilogy/Versata, the organization where I first worked, to give me several opportunities to deliver presentations and workshops to the interns and new hires - including '07 batch of interns, '07 batch of new hires and '08 batch interns.

Discovery of Design Patterns
During my design evangelism at Versata, I developed a technique for introducing design patterns, especially to the uninitiated. It is a 2-step approach that I call Discovery of Design Patterns-

Step 1: Enter the World
A presentation that is meant to be a gentle introduction. It includes-
  • The etymology - why is it called design+pattern
  • Design patterns in other walks of life
  • How they evolved in the software, specifically OO, world
  • Definition of design patterns
  • Introduction to GoF & their work
  • Ignition  - generic design problems we often face
  • The simplest design pattern
  • OO concepts - knowing which does not necessarily mean you can design well!
  • Importance of design drawings for sharing ideas
  • Learning tips
  • A word of advice
  • References
The presentation is here.

Step 2: Find the Jems
A workshop with real world-ish design problems to solve. Every problem is nothing but a programming scenario in which the logic to be encoded is perfectly straightforward. The challenge is partitioning the logic blocks and responsibilities in a neat way. Most often the first solution that strikes turns out to be too cumbersome to read, maintain, reuse or may present similar issues. Every problem is targeted to introduce one design pattern. This is how I typically go about each design problem-

  1. I walk the group through solving the design problem by asking them to come up with solutions. To begin with I suggest them to share the first solution that comes to their mind. In most cases, they are themselves able to point out the issues it has. This marks an important step in helping them understand the common design issues like explosion of objects or classes, controlling the number of instances, triggered changes and so on.
  2. At this point, I nudge them to focus on removing these issues by suggesting alternatives. Either changing some parts of the original design or a complete make over. This step may either expose more issues and end like step 1. Or, it may solve certain problems. This is the right time to make explicit the tiny OO concept they would have applied to fix it.
  3. Hopefully, in a few iterations the group would arrive at a good solution - that is the design pattern itself! And it turns out that I have seen this work with most patterns in all the three groups I have done this with. At this point, all you need to do is spell out the design pattern. Point out its unique structure that may have been critical in solving the different issues discussed. Draw the diagrams and point out the goodness, consequences and shortcomings if any of the pattern.

The key in making this work lies in the ability to analyze the design solution that the group throws up at you. The ability to identify and explain issues, introduce concepts intuitively at the right time and be able to nudge them in the right direction by asking the right questions - and not by just showing the way. Unless the group arrives at the design pattern solution, the exercise does not achieve its fullest effect.

The set of design problems I use is here.

9 Planets
Here is an example of a design problem. I have also captured the minutes from one of the discussions of this problem to make the idea more clear.