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 Eclipse architecture.

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.

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 central abstraction.

Bill Venners: You said TestCase is the core abstraction in JUnit.

Erich Gamma: Actually it is the Test interface which is implemented by TestCase, but yes we started with 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 codified around Test.

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.

Pattern languages

Bill Venners: What is a pattern language, in the Alexandrian sense?

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.