I hear from other developers all the time about how they feel that design patterns are over-hyped and not really useful. For example, recently I was talking to an aquaintance Bob (not his real name), who works for a hugely well-known company.
We were talking about some programming stuff, and as it happens, soon wandered into the world of patterns.
Bob said to me that when he first read the GoF book, he felt that there was nothing new in it. He had already implemented those patterns and had reused them over and over in his designs. So, he said, “What is the big deal with patterns? I did not learn anything new!”
In my experience, this sentiment is pretty common among us developers. I, and my co-authors, received similar feedback during the early days of our work on Core J2EE Patterns. I said to him “Bob, it is great that you had implemented those patterns in the GoF book before it was published. But the very fact that you, me and others like us have repeatedly implemented them proves that those patterns are indeed patterns! And that's the whole point about patterns.”
Documenting recurring designs helps us to communicate with other developers. Patterns provide a great mechanism to document and share reusable problem/solution pairs. Patterns also provide a powerful design vocabulary so everyone on the team can talk the same talk and understand each other. This increases productivity and decreases noise and ambiguity in our design discussions. The benefit of such a vocabulary in design is often an overlooked benefit of using patterns in our day to day work.
In the GoF book, they talk about an Aha! experience – when one understands the patterns and gains new insights. I think the experience I have encountered from other developers is a bit different, one that I call the Duh! effect, as in “Duh! I knew that already.” As a pattern practitioner, when I hear the Duh! effect, I no longer have to prove that patterns are useful and that a pattern is a pattern.
Duh! = Game over!