After finally pressing post my last post on the Singleton Design pattern, I was quite surprised to find Jeff Atwood talking about Rethinking Design Patterns itself. I was however quite pleased to see that he hasn’t contradicted my conclusions.
Jeff proposes that Design Patterns is No Silver Bullet.
But I have two specific issues with the book:
- 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.
- 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.
In fact in the comments he links to a previous post Head first design patterns where he proposes that this other book is a contradiction, the first part of this quote comes from the book.
First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not “how can I apply a pattern to this problem.” Don’t feel like you aren’t a sophisticated developer if you don’t use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern.
Filling 593 pages with rah-rah pattern talk, and then tacking this critical guidance on at the end of the book is downright irresponsible. This advice should be in 72 point blinking Comic Sans on the very first page.
This is very much what I wanted to express. I think that people need to learn and learn and learn. They go through stages where their knowledge doesn’t have sufficient maturity to let them come to the right conclusion. They have to make mistakes first. One of those mistakes is trying to use patterns to solve every problem.
Where I think myself and Jeff differ is that he believes that the books and other sources should come with the warnings that they need to be used in moderation (strangely enough he also comes to a conclusion regarding moderation in the following days post The Technology Backlash). I believe that we need to make the mistakes where we learn why they are mistakes.
I suppose the big question is,
Who can afford for us to learn on their time and make mistakes in their code base as we develop design maturity ?