Among developers, design patterns are a popular way to think about
design, but what is the proper way to think about design patterns?
In this interview, Erich Gamma, co-author of the landmark book,
Design Patterns, talks with Bill Venners about the right
way to think about and use design patterns.
Erich Gamma lept onto the software world stage in 1995 as co-author
of the best-selling book Design Patterns: Elements of Reusable
Object-Oriented Software (Addison-Wesley, 1995) [see Resources].
This landmark work, often referred to as the Gang of Four (GoF)
book, cataloged 23 specific solutions to common design problems.
In 1998, he teamed up with Kent Beck to produce JUnit [see Resources],
the de facto unit testing tool in the Java community. Gamma currently
is an IBM Distinguished Engineer at IBM's Object Technology International
(OTI) lab in Zurich, Switzerland. He provides leadership in the
Eclipse community, and is responsible for the Java development effort
for the Eclipse platform [see Resources].
On October 27, 2004, Bill Venners met with Erich Gamma at the
OOPSLA conference in Vancouver, Canada. In this interview, which
will be published in multiple installments in Leading-Edge Java
on Artima Developer, Gamma gives insights into software design. In
this first installment, Gamma describes gives his opinion on the
appropriate ways to think about and use design patterns, and
describes the difference between patterns libraries, such as GoF,
and an Alexandrian pattern language.
The real value of design patterns
Bill Venners: Bruce Eckel and I teach design classes, and
we've found that people really want to know the Gang of Four (GoF)
patterns. Patterns help sell seminars. There's a lot of marketing
hype around design patterns.
Erich Gamma: Still, after 10 years?
Bill Venners: Yes. People want to know patterns, and I
suspect a great deal of that is because "patterns" is
still a buzzword. I'd like to cut through the hype and find out what
you think people should actually do with patterns. What should their
attitude be about patterns? How can people use patterns to do a
better job? What is the real value?
Erich Gamma: I think patterns as a whole can help people
learn object-oriented thinking: how you can leverage polymorphism,
design for composition, delegation, balance responsibilities, and
provide pluggable behavior. Patterns go beyond applying objects to
some graphical shape example, with a shape class hierarchy and some
polymorphic draw method. You really learn about polymorphism when
you've understood the patterns. So patterns are good for learning OO
and design in general.
Then on top of that, each individual pattern has a different
characteristic to help you in some place where you need more
flexibility or need to encapsulate an abstraction, or need to make
your code less coupled. This is a really big issue in a large
system. How do you preserve your layers? How do you avoid up calls
or circular dependencies? The GoF patterns provide you with little
tools that help you with these problems. They do so not by giving a
pat solution but by explaining trade-offs. Even though patterns are
abstracted from concrete uses, they also provide you valuable
implementation hints. From my perspective it is the fact that
patterns are implementable that makes them so valuable.
Patterns are distilled from the experiences of experts. They
enable you to repeat a successful design done by someone else. By
doing so you can stand on the shoulders of the experts and do not
have to re-invent the wheel. However, since patterns enable many
implementation variations you still have to keep the brain turned
on. Finally, since patterns provide you with names for design
building blocks they provide you with a vocabulary to describe and
discuss a particular design.
The other question was how we should teach patterns. Not that I
know exactly what you should do, but I think what you should not
do is have a class and just enumerate the 23 patterns. This approach
just doesn't bring anything. You have to feel the pain of a design
which has some problem. I guess you only appreciate a pattern once
you have felt this design pain.
Bill Venners: What pain?
Erich Gamma: Like realizing your design isn't flexible
enough, a single change ripples through the entire system, you have
to duplicate code, or the code is just getting more and complex. If
you then apply a pattern in such a messy situation it can happen
that the pain goes away and you feel good afterwards. It's an eye
opener to realize that oh, actually this pattern, factory or
strategy, is a solution to my problem. And I think that's the really
interesting way to teach.
When I started teaching it was really boring, because I was just
enumerating the patterns. I found it far more interesting to try
to motivate with real examples how to apply patterns. In other words,
you really need to present the problem in a realistic context—synthetic
examples do not fly. At OOPSLA I received a Heads First Design
Patterns book [see Resources]. It's a great book, not only
because it is fun to read but also because they are able to communicate
the essence of design patterns in a novel and highly visual way.
Bill Venners: Is the value of patterns, then, that in the
real world when I feel a particular kind of pain I'll be able to
reach for a known solution?
Erich Gamma: This is definitely the way I'd recommend that
people use patterns. Do not start immediately throwing patterns into
a design, but use them as you go and understand more of the problem.
Because of this I really like to use patterns after the fact,
refactoring to patterns. One comment I saw in a news group just
after patterns started to become more popular was someone claiming
that in a particular program they tried to use all 23 GoF patterns.
They said they had failed, because they were only able to use 20.
They hoped the client would call them again to come back again so
maybe they could squeeze in the other 3.
Trying to use all the patterns is a bad thing, because you will
end up with synthetic designs—speculative designs that have
flexibility that no one needs. These days software is too complex.
We can't afford to speculate what else it should do. We need to
really focus on what it needs. That's why I like refactoring to
patterns. People should learn that when they have a particular kind
of problem or code smell, as people call it these days, they can go
to their patterns toolbox to find a solution.
Bill Venners: That's funny, because my second question was
that I have observed that often people feel the design with the most
patterns is the best. In our design seminar, I have the participants
do a design project, which they present to the others at the end of
the seminar. Almost invariably, the presenters want to show off how
many patterns they used in their design, even though I try to tell
them the goal is a clean, easy to understand API, not to win an
I-used-the-most-patterns contest. I just heard you say the same
thing, that that's not the right way to think about patterns. If
not, what is the proper justification for using patterns in designs?
Erich Gamma: A lot of the patterns are
about extensibility and reusability. When you really need extensibility,
then patterns provide you with a way to achieve it and this is cool.
But when you don't need it, you should keep your design simple and
not add unnecessary levels of indirection. One of our Eclipse mottos
is that we want extensibility where it matters. Actually, if you
are interested in how we use patterns in Eclipse I did an attempt
to capture their uses in a chapter in the Contributing to Eclipse
book [see Resources].
In this chapter I used design patterns to explain pieces of the
Bill Venners: By extensibility, what do you mean?
Erich Gamma: That you can customize behavior without
having to touch existing code—one of the classical OO themes. You
can reuse something adapted to your particular problem.
Core abstractions surrounded by design patterns
Bill Venners: In an article you wrote with Kent Beck, called
"JUnit: A Cook's Tour," [see Resources]
you walk the reader through the design of JUnit by, as you wrote,
"starting with nothing and applying patterns, one after another,
until you have the architecture of the system." I thought perhaps
this approach may be inspired by Christopher Alexander, whose work
on patterns in architecture inspired the software patterns movement.
Do you feel that layering one pattern on top of another until you're
done is an effective way to design?
Erich Gamma: The Cook's tour is kind of synthetic. We
reconstructed the design we did on JUnit. However, we didn't develop
JUnit in such a pattern driven way, instead we did it in a strict
test-driven way. What is true in JUnit is that there is a core
abstraction for a test, and around that core abstraction you see
several other design points emerge, which in turn are materialized
by pattern instances. That's something you can often observe in
mature designs. There are some key abstractions you often see as a
design center, and around those key abstractions you want to achieve
various things. So you see patterns growing out of such a center.
But I wouldn't use this as quality criteria.
Bill Venners: Is that what you're referring to when you
say, "pattern density?"
Erich Gamma: Yes, exactly, patterns popping-up around some
Bill Venners: You said
TestCase is the core
abstraction in JUnit.
Erich Gamma: Actually it is the
interface which is implemented by
TestCase, but yes we
TestCase and expanded from there.
Bill Venners: And then, could you define density? The
number of patterns around it? You said the JUnit Cook's Tour was
kind of synthetic.
Erich Gamma: Synthetic in the sense that the cooks tour is
what is left over when you strip out all the test activity that
happened during our test-driven development. Therefore it is a very
compressed presentation. The density shows up in the patterns
We didn't just string patterns together when we designed JUnit.
We did it test-driven, starting with a test that we wanted to
succeed and once it passed we looked into how we could improve the
code. Developing a test framework in test-driven way isn't without
its challenges, but once you have the basics working it goes
surprisingly smoothly. You see, Kent and I were fluent in patterns
when we designed JUnit. So of course, we'd say things like,
"Hey, that's composite." Composite is a pattern in JUnit.
We also use template method. That's a basic one. We have command.
This is of course a key one. We started with test and said,
"Oh, this is a command. Oh, this is a template." Because
we were fluent in patterns, our conversation was going really fast,
enabling a high-velocity design.
This actually illustrates nicely how patterns provide us with
design vocabulary. Similarly when you look at a UML diagram, then
you see boxes and arrows, but they don't really tell you the meaning
behind these relationships. But once you know the pattern then it
explains what these relationships are about. If it's observer, it's
really clear why there is a link between these two classes. It's
because this guy observes that guy. You know exactly what's going
on. And I guess that's the key point. Patterns give us a language to
talk about design. Actually, the JUnit journey isn't over yet and
Kent and I are currently working on JUnit 4. We are continuing to
evolve JUnit in a test-driven way. One of our themes is to lower the
barriers to entry. To do so we are leveraging J2SE 5 features like
annotations to make JUnit easier to use.
Bill Venners: What is a pattern language, in the
Erich Gamma: Alexander had a very ambitious goal which was
to create architectures that improve the quality of life. To achieve
this Alexander developed a pattern language. This is a set of
patterns that build on each other. A pattern language guides a
designer's application of individual patterns to the entire design.
When we started design patterns we were not that ambitious. We used
a more bottom-up approach based on micro-architectures.
Bill Venners: What do you mean by bottom up?
Erich Gamma: Let me step back a little and describe how I
got into patterns. I think that will answer your question. I was
working with Andre Weinand on ET++, a comprehensive class library
and framework for C++. As I reflected on ET++, it became apparent
that a mature framework contains recurring design structures that
give you properties like extensibility, decoupling, and last but not
least, elegance. Such structures can be considered
micro-architectures that contribute to an overall system
architecture. I ended up documenting a dozen or so such
micro-architectures in my thesis. This approach to patterns differs
from pattern languages: Rather than coming up with a set of
interwoven patterns top-down, micro-architectures are more
independent patterns that eventually relate to each other bottom-up.
A pattern language guides you through the whole design, whereas we
have these little pieces, bites of engineering knowledge. I confess
that this is less ambitious, but still very important and useful.
Bill Venners: Is a pattern language like having a context
free grammar, and from which you can make a whole bunch of programs?
Erich Gamma: There are some similarities at an abstract
level. In the same way as a grammar can define a whole bunch of
programs a pattern language can generate a bunch of solutions. The
way Christopher Alexander describes it is that his patterns describe
a solution so that it can be applied many times without ever being
the same. But in my opinion at this level the commonality ends.
Bill Venners: By generate, what does he mean? If I have a
context free grammar, it doesn't generate the programs. I still have
to write them.
Erich Gamma: You still have to make the decisions, but a
pattern language provides you more guidance and it has some flow.
Say you want to design a room in which you are comfortable. He says,
first put lights on two sides. OK, now that you have done lights on
two sides, what comes next? How do you place the windows? There are
other patterns that describe a solution to this problem. He
basically guides you through the space. This kind of connection is
what differentiates a library of patterns as we have described in
the GoF book from a pattern language. What we have found is that our
micro-architectures are also no islands. They are related. We
sketched these relationships on the inside of the book cover, and
this is what Alexander enthusiasts consider the only valuable part
of our book.
Bill Venners: It sounds almost like a design methodology.
You go this way, do this, this, and this, and you end up with a
beautiful, comfortable to sit in room.
Erich Gamma: Yes, when you follow Alexander's patterns approach
you follow the patterns in some sequence. We don't prescribe a particular
order. If you have a problem, we have the solution for that, but
we don't have the next step. We don't give you hints on what to
do next. Alexander is way more thorough in this regard. JUnit has
a bit of this pattern language approach, because it can help you
write a test case. In the JUnit documentation, Kent and I wrote
a mini pattern language on how to implement a test. You start with
a test, then you want to factor out common setup code, then you
want to group tests together and so on.