This is an old revision of the document!
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). 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, 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. 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.
Yann-Gaël Guéhéneuc, 2014/04/07
This conversation with Erich Gamma is actually in five parts. Each with its own theme but all revolving, of course, around design, design patterns, API, releases. The main theme being “the appropriate ways to think about and use design patterns, and […] the difference between patters libraries, such as the GoF, and an Alexandrian pattern language”.
In the introduction of the first part (and elsewhere), Gamma and Venners define design patterns and their characteristics. Nothing new in the definitions, which mentions polymorphism, composition, delegation, responsibilities (cohesion), abstraction, coupling. Gamma also mentions that design patterns offer micro-architectures that contribute to an overall system because they “are implementable [and] that makes them so valuable”. Design patterns are “less ambitious” than “a pattern language [that] provides you [with] more guidance”. This guidance is what Alexander enthusiasts seek with the relationships among design patterns.
They also mention the characteristics of flexibility, duplicated code, change ripples, extensibility and reusability (defined as customising behaviour without having to touch existing code)
Regarding teaching design patterns, I was happy to read that going through the 23 design patterns is not the way to go! Rather, Gamma points out that “[y]ou have to feel the pain of a design which has some problem”, “[l]ike realising your design isn't flexible enough, a single change ripples through the entire system, you have duplicate code, or the code is just getting more and complex”.
Gamma advises not to start with patterns but rather refactoring to patterns by “really focus[ing] on what [the design] needs” because “we want reusability where it matters”. Therefore, the process of using design patterns is to identify first “some key abstractions you often see as a design center, and around those key abstractions you want to achieve various things”.