Design Patterns

Thursday, August 4th, 2005

“In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about how design patterns are problem solution pairs, how design patterns help you understand intent and tradeoffs, and how to become a better designer through practice.”

Some pieces that caught my eye:

Bill Venners: In the GoF book you and your coauthors say, “Knowing these design patterns can make you a better designer.” How? Don’t I still need to know when to apply them?

Erich Gamma: Yes, do not turn off the brain; your creativity is still required. It isn’t always clear when to apply a design pattern. In addition you also need to know which variation of a pattern to apply, and how to tweak the pattern. You always need to adapt a pattern to your particular problem.

Removing a pattern can simplify a system and a simple solution should almost always win. Coming up with simple solutions is the real challenge.

Erich Gamma: In addition to reading books, you need to read and understand lots of code, see how existing systems solve a particular problem and what experienced designers did. Basically what design patterns do is to tell you what these developers have done. But, just reading about it isn’t enough. You become a master by mimicking the work of excellent developers.

I’m not saying I’m an experienced designer or anything, but I’ve always frowned upon the use of patterns. I really don’t see the use in getting a prefabricated solution from a book when it’s just as easy to come up with the sollution yourself. The problem isn’t with using patterns perse but with the underlying idea: prefabricated sollutions. An electric engineer need not understand the internals of the Integrated Chipset he uses. Likewise, the Software engineer needn’t understand the libraries he uses. BUT, the should always understand the structure of what he’s building and, more importantly, understand why he’s building it like that.

Basically, I see design patterns as something for inexperienced programmers with little or no imagination or creativity. So far, the writers of the book seem to agree with me. But I’ll take it one step further and say: all it does is stiffle those people’s creativity and keep them from ever learning to find sollutions on their own.

When I was younger, I used to spend nights and nights lying awake thinking about the best possible sollution to this or that programming problem. Nowaydays, when I see some of these design patterns, I find that they’re usually the same as the what I figured out for myself back then. The big advantage of having thought out the sollution for myself is that I can easily determine the cases in which the ‘pattern’ is not the best way to go (usually because I already dismissed it for several other similar problems when coming up with a new sollution for something).

Actually thinking about ways to perform a certain task for yourself, instead of letting some book do the thinking for you, teaches you so much more than following some prefabricated sollution. It’s somewhat similar to finding an awnser to a question yourself by consulting API documentation, books, other people’s source-code, etc instead of simply asking a guru. During the ‘researching’ you’ll encounter tons of information that might not be of any use in your current situation but which may prove to be indispensable later on.

Even though the author, Erich Gamma, does try to convince everybody that you don’t become a good developer/designer by just reading books on patterns or applying patterns, he fails to mention that you can only become a good developer by understanding patterns. Perhaps the real problems shines through when he says: “You become a master by mimicking the work of excellent developers“. That’s what Design Patterns seem like to me.. mimicking. But everybody can mimick someone else.

He should have said: “You become a master by understanding the work of excellent developers”.