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.
I think what Jeff is trying to say is that people see the patterns and think "this is way cool" and then try to make them the hammer that solves every problem nail. In other words, the question becomes "which pattern applies" instead of "what's the best solution"?
ReplyDeletePeter Norivg demonstrated that "16 of 23 patterns" were either simpler or didn't need to exist in a language like Lisp or Dylan way back in 1998, http://norvig.com/design-patterns/.
The bigger issue is that it's the Blub paradox: if you haven't tried another language, you don't know what you're missing. For example, a "foreach" iterator can remove a lot of for/while loops or at least make the current ones more robust (no off-by-one errors). But if you don't know there is such a thing, you won't miss it. Sure, the pattern solves the problem, but there might be a more elegant way to do it.
Another thought: if a language has a ton of patterns, perhaps it's not very powerful.
Steve thinks every coder should read the classic GoF "Design Patterns": Are Design Patterns A Bad Idea?
ReplyDeleteSteve thinks every coder should read the classic GoF "Design Patterns": Are Design Patterns
ReplyDeleteOnly when you have time, resources, long term vision will you think of patterns. Otherwise you can follow only one patern GIGO (Garbage in Garbage Out).
ReplyDeleteI'm not a perfect programmer.
ReplyDeleteI can admit to writing code that I realize, in hindsight, was over-engineered. I can also admit to refactoring to elegant solutions, but in hindsight asking myself, why didn't I see that sooner?
Patterns help me both when I use them and when I decide they're overkill. Hopefully, I will continue to improve my aim.
Jeff should answer the following fundamental question:
ReplyDeleteWhat programming construct does almost every Design Pattern have in common with each other ? Answer: Polymorphism
How can a polymorphic behavior be made "simpler" ? I guess that he prefers writing large blocks of procedural if-then-else statements
I'm starting a new category. It's going to merely include quick blurbs from your's truly and links...
ReplyDelete