Design Patterns have always made me bristle a little bit. Maybe it’s just my inner contrariness but I believe that each problem has it’s nuances and that too much faith in Pattern will make you graft simple pre-made solutions on to complex real-life problems. I’ve always felt that it’s necessary to know the patterns, to have them in your tool-belt as a starting point for ideas, but that to be insistent about, or dependent on, the Design Pattern, confuses Pattern with Solution; the Starting point with the Finish line.
Sadly, I am not so articulate as this guy when it comes to this issue: http://blog.plover.com/2006/09/11/
On the face of it, his claim is that Design Patterns represent “signposts to the failures of the programming language”.
I think his larger claim is about the evolution of languages; that each language should be looked at as just the middle ground on a long uphill climb toward more expressive power, and that each Pattern codifies the frustrations of the programmers using it to do these often-needed things. To drive innovation, he would say, one should always be looking for ways to take Design Patterns and co-opt their power by making them invisible.
I couldn’t agree more.
And the corollary of course is that Design Patterns should be bristled at, used grudgingly, and as the starting point for discussion. Another way to say it might be, compliance with a Design Pattern is not a very good measure of Quality.