A Conversation with Erich Gamma, Part I
by Bill Venners
May 23, 2005
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
On October 27, 2004, Bill Venners met with Erich Gamma at
the OOPSLA conference in
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 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.
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 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.
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.
An Interview with Paremus' Robert Dunne from JavaOne 2007
by Frank Sommers and Bill Venners
August 21, 2007
In this interview with Artima, Robert Dunne, principal software engineer at Paremus, discusses three levels of dynamism, and why it's so difficult to deal with "impolite" services.
The problem of error-handling is as old as the need to decide just how much margin of safety to provision for in a system. As software systems become increasingly heterogeneous, this question frequently comes up when relying on services over which a developer has little control: services that often come from the network, and that may appear or disappear at any time.
In this interview with Artima, Robert Dunne, principal developer at Peramus, distinguishes between static services, polite services, and impolite services, and discusses why it's so hard to deal with the latter:
You can have three levels of dynamicity. The first one is no dynamicity at all: everything is very static. [That's] the kind of thing you get these days in sort of pojo-like frameworks where, given your dependencies at start-up, there is a fixed set of dependencies...
There's another level, which is what you can encounter with OSGi: within a single VM, you have a number of services written by a number of different people that may be coming and going independently of each other. They detect each others' presence, and also detect a service's departure. These services are "polite" in that sense: you always get told when they arrive and when they go.
And then further down you've got distributed systems where there is a network in the way, and things may disappear without saying good-bye. There may be network failures, there may be temporary outages, and you don't have full information [of the cause]. So that's kind of an "impolite" environment, and a more difficult one to deal with.
Even to manage polite services, [that] is not something people are all that familiar with. The coming of things like Spring OSGi means that people really need to start thinking about these things a lot more. [Managing polite services] is just a question of keeping your eye out in the VM for some new party that's providing you something... The fact that things say good-bye means that you've got a level of certainty.
[Managing] impolite services is the tricky one. A lot of today's infrastructure doesn't acknowledge the existence of impolite services. Systems [that] have a static nature, you can't rely [on] in a distributed world. Our way of looking at distributed systems is that your infrastructure and your application better be at least as dynamic as the environment it wants to survive in... There are a number of things you might expect to change in your environment, and that you can code for. You can't code for everything, but within a wide range of things you can code for these scenarios. That's the level of dynamicity you're able to tolerate.
Dunne compared the level of dynamicity a system can tolerate to relying on the bus schedule to get to work each day:
If your assumption about the world is that there will be a bus along every day within a given range, then that's kind of a polite scenario, really. You're saying that you're not going to tolerate very much of a diversity, that this is how things are going to be.
If that's what you've coded for, but actually the bus may from time to time not come, then you've got problems—you're not going to get to work that day. So you're probably going to code for a wider range of things: [If] the bus doesn't come, call a cab. If the cab doesn't come, try to get there on your bike.
At some point you're going to hit a level at which you haven't coded for the dynamicity that's really there. There may be an earthquake. It's not reasonable for you to plan for that. There's always a trade-off.
How do you decide what level of dynamicity you design for in your systems?
Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.
Bill Venners is president of Artima, Inc. 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.