It all started earlier this month when Jeff atwood (Coding horror) criticized the GoF Design Patterns book. Jeff wrote that, while he think the book is should be read by every programmer he still has two main problems with the book:
1. Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.
2. If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering-- it's a sign that your language is fundamentally broken.
Jeff also quotes Mark Dominus who thinks that the GoF book obstructs the ideas of Christoper Alexander et al. who wrote the (building) architecture book "A Pattern Language - towns, Building Construction" (which is considered as the inspiration for the whole design pattern movement in computer science)
Steve Rowe agrees that the patterns should be used as examples of good design and principles to apply and not as a reference book but he says that Jeff is off the mark because he attacks the concept instead of the way where the blame is on the people who apply them wrongly. He concludes that patterns should be treated as examples for good design not as dogma:
Design patterns are very useful when we study how they work so we can create similar patterns. They are bad when we try to copy them directly. If one reads the Gang of Four, he will realize that the authors often give several examples of each pattern and they're all slightly different. One might also notice that there is a lot of talk about the OO concepts that lead to the patterns.
Cedric Otaku answers both Jeff and Mark's criticism in a post he called "In defense of Design Patterns". Cedric says that Jeff (and Mark before him) are wrong for criticizing the GoF book, without offering any alternative. Cedric, goes on to explain the problem with making a parallel between Alexander's construction design pattern and software design patterns
There is a reason why it's important to establish a clear separation between Alexander's Design Patterns and the GOF's Design Patterns: software engineering is nowhere near as advanced as building engineering is. We are still working on these nuts and bolts, and whenever a new software project starts, we still can't be sure it won't collapse under its own weight after just a year. To make a parallel: imagine a world where every time a new construction takes place (say, a bridge), the future of that bridge depends on the team of engineers and workers you choose to build it...
Cedric says that because construction is far more advances (in its predictability and stability) than software is. we are still struggling for the basics and we should be focused on that.
On the other hand a Aristotle Pagaltzis left a comment on Cedric's blog and rationalized Mark's critisism
Dominus says that design patterns are a sign of a deficiency of a language for the purpose that the design pattern addresses. In other words, the Visitor pattern used in Java points to the fact that Java is deficient in terms of list processing: the `map` and `filter` constructs need to be emulated with lengthy OO incantations.
He is _not_ saying that the use of design patterns _as such_ is bad. He is saying they are a sign of a deficiency.
It seems most (if not all) agree that patterns as tool in software engineering is useful, the debate is on the value of the GoF book today. What do you think ? is the Gof Design Patterns a timeless piece or has it outlived its purpose ?