Are Design Patterns A Bad Idea?
Jeff Atwood has some issues with the idea of Design Patterns. His issues are basically:
- People use design patterns when they could use a simpler solution.
- Recurring patterns indicate a place where the language is weak.
Read his post for the details. I think Jeff makes some good points but misses the mark. First, his comment about it being a language issue is interesting, but more often than not we don't have a choice of languages. Not just because our bosses dictate the language, but because most languages have serious weaknesses and even if they solve our pattern problem, they may not be robust enough, have the right libraries, be what the team knows, etc. Second, he's attacking the concept when it's really an implementation of the concept that deserves his criticism. His point about using patterns when people could write simpler code is correct, but isn't really the fault of the book or the concept. It's a problem with the way people use them. 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.
I've always been skeptical of using the patterns as a shared language. They shouldn't be treated like a classification system. They should be used as examples of good design principles to apply where appropriate to other code. If you can understand why the patterns are useful, you'll be able to create them without memorizing them. You'll have code that is flexible, but not overly complex.
Every programmer should read the Design Patterns book. They should do so to learn the rules of good design though, not as a reference work.
