Design patterns are ideas for solving problems that commonly occur in software development. Patterns provide a language framework for programmers, helping us to discuss abstract concepts in an efficient manner.
If you’re not familiar with design patterns, I highly recommend reading the seminal work by the Gang of Four: Design Patterns: Elements of Reusable Object-Oriented Software. Its a bit dry but an excellent read. I remember when Joshua Storck recommended the book to me many years ago; it opened my eyes to a higher level of programming and helped me grow from a task implementer to a software designer.
Patterns are helpful for structuring thought around problems and forming elegant solutions. However, there are a few things to keep in mind: Patterns have consequences, and patterns are not best-practices. Programmers must still apply thought. Terry Chay describes this in his article, Challenges and Choices.
I just came across an article by Amy Hoy in which she describes the dangers of over relying on patterns. She’s spot on:
People no longer treat patterns as the shared wisdom of experts, however. They are inclined less to bang their heads against a problem and then consult the Book of Wisdom to see what it says about their particular problem. Instead, they treat patterns as Wal-Mart for decisions. They don’t know what they want, exactly, but hey, this little item here on the shelf looks like a potential candidate.
They start with a pattern and see how to make it fit.
This is bassackwards.
We all build our own patterns around problems we’ve encountered. But just as with design patterns, its important that we force ourselves to think through problems creatively before jumping to more commonly treaded paths.
