Design Patterns have been around for some time now but many of us are still learning how and when to leverage these powerful concepts for engineering software.  Design Patterns have also been the source of backlash for those who have suffered under design pattern crazed architects.  As with any useful tool or concept the balance lies somewhere in the middle.

Patterns exist even when you don’t see them.  If I had to choose a way to describe my early programming career (classic ASP & MS Access/MySql) it would be “DRY” (don’t repeat yourself).  I spent a lot of time doing things to avoid duplicate work.  In ASP this meant lots of include files and shared routines.  This led to some common patterns that I used to tackle certain problems; by no means were these actual design patterns, it was just a way I found to best solve the problems I encountered.  Looking back on that early experience I see how the design patterns could have helped.

When framing the problem if you see a pattern try to leverage it to solve the problem.  Before the holidays the project architect (We’ll call him “Brad”) and I were trying to tackle a problem.  As he was looking at what we were doing he suggested the strategy pattern.  We weren’t sure it was a good fit but it gave us something to look at to help us with the problem.

One of the barriers to understanding patterns is a lack of real-world examples.  If you study the strategy pattern I referred to above you’ll see most of the examples discuss simple calculations, A+B type of stuff.  That is helpful, but what if I have 4 factors that are needed to calculate the price and there is other data we must include with the price, like if there was a discount, etc?  Does that mean I can’t use the strategy pattern?

Patterns require you to generalize and forget about your specific domain.  This is probably the hardest part.  A lot of people think that their situation is totally unique; for the domain it may be, but in reality a lot of people have the same problems.  This is where patterns really help.

One of my goals for 2010 will be to continue studying and applying patterns where they fit.  Some great resources I’m using are: