====== Venners, B. Leading-edge Java — A Conversation with Erich Gamma. 2005 ======

===== Abstract =====

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.

===== Comments =====

//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".

==== On Design Patterns ====

Gamma and Venners define design patterns and their characteristics. Nothing new in the definitions, which mention polymorphism, composition, delegation, responsibilities (cohesion), abstraction, and coupling. Gamma explains 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 thus "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. Yet, design patterns are in the "middle level" between class libraries on the one side and frameworks on the other. Gamma recalls that "[a] pattern is always a problem—solution pair that can be applied in a particular context" and that, if some design patterns have the same solution, it is the problem that is different. Thus, the "pattern[s] [tell] you about the intent but also about the trade-offs"

Gamma and Venners also mention the characteristics of flexibility, duplicated code, change ripples, extensibility and reusability (defined as customising behaviour without having to touch existing code) as reason for using design patterns, providing examples and explanations but without being systematic. With respect to these characteristics, Gamma makes the point that "[r]emoving a pattern can simplify a system and a simple solution should always win".

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". He also highlights that "you need to read and understand lots of code" before mastering design patterns or design in general and that it helps to "[mimick] the work of excellent developers" and that it "doesn't hurt to contribute to an open source project". **"Bottom line is that you learn patterns by programming."**

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", i.e., "refactor to the patterns once [we] need the flexibility". 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" and to start abstracting only when you start to have two, three, more examples that call for some abstraction because of duplicated code.

==== On APIs ====

A whole [[http://www.artima.com/lejava/articles/designprinciples.html|part]] is dedicated to API and the two principles at the source of design patterns: 
  * program to an interface, not an implementation;
  * composition versus inheritance.
The arguments are usual and recall the discussion by his former colleague [[evolving_java-based_apis|Des Rivières]] but with an emphasis on dependencies and how "[it]'s easy to add a dependency on a class. It's almost too easy" and on abstract classes wrt. interfaces, because abstract classes can have behaviours added without breaking existing clients. Gamma also recalls that "abstractions plus the methods names define the vocabulary" of a software system. He also reminds that "[c]omposition is using inheritance, but typically you just implement a small interface" rather than sub-classing deep, large hierarchies. This argument recalls also the principle of [[http://stackoverflow.com/questions/4205130/what-is-duck-typing|duck typing]] and that, with composition, "you get customisation by configuration".

==== On Shipping ====

Finally, a whole [[http://www.artima.com/lejava/articles/eclipse_culture.html|part]] is dedicated to shipping in which Gamma details the six-week release cycle of Eclipse milestones, with one week planning, and one week testing/building. The last week is typically as follows: "candidate build on Tuesday, testing on Wednesday, fixing critical bugs in Thursday, and declaring the milestone build on Friday". He also explains that "the final version of the plan is done the day we ship" with the "committed or proposed" items clearly defined.