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!

Comments:

Patterns are the first step the software engineers are making towards becoming *real* engineers. Real engineers use the prior experiences of others as the foundations of new projects. In the physical world, though, these experiences can be precise, i.e. this bolt has that shear strength, or use this type of beam in marine applications. Patterns are a way of approching this type of specification in software.

Posted by Brian Utterback on March 18, 2005 at 08:09 AM PST #

Post a Comment:
Comments are closed for this entry.

This blog copyright 2007 by alur