The Artima Developer Community
Sponsored Link

Leading-Edge Java
Patterns and Practice
A Conversation with Erich Gamma, Part IV
by Bill Venners
June 21, 2005

<<  Page 2 of 2


Applying design patterns

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.

This might be a good spot for a little confession about Design Patterns—in the book we only tell when to apply a pattern, but we never talk about when to remove a pattern. Removing a pattern can simplify a system and a simple solution should almost always win. Coming up with simple solutions is the real challenge.

Bill Venners: A lot of people want to become a better designer, and they want to go to this book to help them get there, but just reading the book doesn't...

Erich Gamma: ...doesn't make a better designer. I agree. Learning patterns—and even more important, design—from reading books just doesn't work. And, these days there are also several other interesting pattern books, so don't stop pattern reading after the GoF book.

Bill Venners: What does make them a better designer? What do they need to do?

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. There are many interesting open source projects available that can serve as interesting reading material. Eclipse is just one of them. It also doesn't hurt to contribute to an open source project. Not only do you learn about a particular development process you will also learn how to communicate about a design in a group of developers. As a good designer you not only come up with good designs you also communicate and defend them. You have to practice, like an apprentice in a way. Over time you'll become as experienced as experienced designers.

Practice, practice, practice

Bill Venners: In the GoF book, you write, "It is easiest to see a pattern as a solution, as a technique that can be adapted and reused. It is harder to see when it is appropriate—to characterize the problems it solves and the context in which it's the best solution." How do new designers figure out that. Let's say they go through the book, and they understand the patterns. Now they've got to do their job. How do they learn to know when it is appropriate to use a pattern versus when they are succumbing to the "patternitis" disease of trying to use as many patterns as possible?

Erich Gamma: Unfortunately, a lot of this you only learn later on in the game, once you can look back on what you did—with experienced eyes. If I were a new developer, I'd want to have a mentor or buddy. I'd program with them, and then the mentor would say, "Ping, now this is really ugly," or "oops, you have just expressed the same again that you expressed over there" . The mentor provides immediate feedback and provides pointers to dig deeper. This is just one flavor of pair programming. It's also an excellent way to improve your skills. I always learn something from a pair programming session and I wish I would do it more often.

Bottom line is that you learn patterns by programming. And, not just toy examples; real life examples. But no, you cannot learn patterns just from reading a book. With just a book you might not initially understand them fully. Once you start applying a pattern to one of your own programming problems, you start to understand it a lot better and are ready for the next learning iteration.

Next week

Come back Monday, June 13th for the next installment of this conversation with Erich Gamma. If you'd like to receive a brief weekly email announcing new articles at Artima Developer, please subscribe to the Artima Newsletter.

Talk back!

Have an opinion about the design patterns topics discussed in this article? Discuss this article in the Articles Forum topic, Design Principles from Design Patterns.


[1] Erich Gamma is co-author of Design Patterns: Elements of Reusable Object-Oriented Software, which is available on at:

[2] Erich Gamma is co-creator of JUnit, the defacto standard Java unit testing tool:

[3] Erich Gamma leads the Java development effort for the Eclipse tool platform:

[4] Christopher Alexander described architectural patterns in works such as, A Timeless Way of Building. Oxford University Press, 1979, available on at:

[5] Contributing to Eclipse: Principles, Patterns, and Plug-Ins, by Erich Gamma and Kent Beck, is available on at:

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

<<  Page 2 of 2

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use