Put More Tools in your Toolbox
What's in your toolbox?
All developers acquire a toolbox. It starts when we’re first learning to program with variables, loops, ifs, functions, etc. As we learn more, we add more tools, such as data structures and algorithms into our toolbox. I view design patterns as more tools to add to the toolbox. The more tools a developer has in his or her toolbox, the more options he or she has when facing a design or implementation challenge.
A developer can get by with a surprisingly small number of tools in the toolbox. It doesn’t take much to be Turing Complete. Developers can often solve a problem with their existing tools or build new tools from those tools. But a limited toolset can limit a developer’s effectiveness, and it may lead to implementations that work, but just aren’t quite right. If you have only one tool, then you run the risk of Maslow’s Hammer: When the only tool you have is a hammer, every problem looks like a nail.
Tool use is not evenly distributed. Some tools are used much more often than others. Hammers, screwdrivers, and pliers are used in many scenarios. In contrast, a kitchen drain wrench has only use, but when you need it, that’s the only tool that will work. The same type of distribution occurs with software design patterns. There are some I use repeatedly and some I’ve rarely used if ever. But sometimes that rarely used design pattern is the only one that will easily solve the problem.
When developers first learn the design patterns, they begin to see potential applications everywhere … including places where they probably shouldn’t be using them.
There’s the risk of over-engineering. I have fallen victim to this myself, and I try to be vigilant to keep my over-engineering in check.
There is no easy answer to this. I can only offer these nuggets of advice:
- “Good judgement comes from experience, and experience comes from bad judgement.” – Attributed to many
- “Experience is a cruel teacher because she gives you the test first, the lesson afterwards.” – Vernon Law
- “You haven’t mastered a tool until you understand when it should not be used.” – Kelsey Hightower
Gang of Four (GoF) author, Erich Gamma, told this in an interview from 2005:
One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.
Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs.
Design patterns are not a game to collect all the loot. Design patterns are not solutions in search of a problem. Don’t change the problem just so you can shoehorn a design pattern into it.
Make sure you have the type of problem that a design pattern is intended to address before using it in a design. The only way you’ll know when you’ve done it correctly is to do it incorrectly a few times. Unlike some carpentry tools, using a design pattern incorrectly probably won’t cut off any of your fingers.