Yes, design patterns are!

Lately they seems to be some kind of critique of design patterns (like singletonitis, even a discussion in comp.object). I agree that's some pattern abuse is occurring.

I just read Cedric's defense of design patterns

Mainly about this presentation from M. J. Dominus ”Design Patterns aren't” (http://perl.plover.com/yak/design/samples/slide001.html).

I believe that Dominus's presentation (or the title) misses the purpose of the GoF design patterns. They are object oriented design patterns and Alexander's patterns are architectural design patterns, (architectural in the sense of building, not software). They refer to a different design..

So, yes: design patterns, are!

What they are? Common solutions to OO design problems (not a library of C++ templates!).

New languages (or not so new) with greater flexibility make some of the GoF patterns unnecessary, because they're solved by the language itself and the problem doesn't appear.

Granted, lot of people will jump directly to apply the pattern without understanding what are the forces behind that particular pattern leading to apply the pattern in the wrong context. Maybe that's a downside of the popularity of the GoF patterns: people just apply the patterns without bothering to learn OOAD. A pattern should be the “missing piece of the jigsaw” that when put in place unifies all the forces harmoniously.

For me, one of the greatest value of the design patterns was to show the usefulness of the patter format to capture reusable knowledge: naming common solutions for recurring problems and the implications of that particular solution. As an example, (software) architectural patterns are an easy way to convey an architectural style by just mention the pattern name (e.g. layers, pipes and filters, blackboard, etc.)

Along the success of the GoF book, a whole pattern movement emerged for software and now we have architectural patterns, high level design patterns, low level design patterns, technology specific design patterns (like the J2EE patterns), analysis patterns, even business modeling patterns.

I somewhat agree that people went overboard with the patterns and need to stop overusing them and get past the 25 patterns of the book. (Every book now seems to need “patterns” in the title... and “agile” too... if I have to title a book I would name it “Agile Patterns of Refactoring Driven Design with UML”)

So, in spite of the criticism I really see value in patterns.