Design patterns are one of the most valuable tools available to the software architect. Using patterns allows us to create common solutions that are easier to communicate and understand. They are concepts that are directly associated with good design. This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project. If you find yourself trying to shoehorn your favorite patterns into a problem space where they don‘t apply, you may be a victim of pattern pathology.
Many projects suffer from this condition. These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying “Now, which one will I use first!?”. This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”. Design patterns are excellent tools for mitigating necessary complexity but like all tools, they can be misused. Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail. Be careful that your appreciation for patterns doesn‘t become an infatuation that has you introducing solutions that are more complicated than they need to be.
Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn‘t automatically qualify a solution as good design. They are reusable solutions to recurring problems. They have been discovered and documented by others to help us recognize when we‘re looking at a wheel that‘s already been invented. It‘s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately. Don‘t let your desire to exhibit design pattern knowledge cloud your pragmatic vision. Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.
