User Tools

Site Tools


leading-edge_java_a_conversation_with_erich_gamma

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
leading-edge_java_a_conversation_with_erich_gamma [2014/02/07 08:17]
yann
leading-edge_java_a_conversation_with_erich_gamma [2017/09/06 01:54] (current)
Line 11: Line 11:
 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"​. 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"​.
  
-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. ​+==== On Design ​Patterns ====
  
-Gamma and Venners ​also mention the characteristics ​of flexibilityduplicated codechange ripplesextensibility and reusability ​(defined as customising behaviour without having to touch existing codeas reason for using design patterns, ​providing examples ​and explanations but without being systematic.+Gamma and Venners ​define design patterns and their characteristics. Nothing new in the definitionswhich mention polymorphismcompositiondelegation, 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. Yetdesign patterns are in the "​middle level" between class libraries on the one side and frameworks on the otherGamma 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"​
  
-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 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. 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: ​ 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;​   * program to an interface, not an implementation;​
   * composition versus inheritance.   * composition versus inheritance.
-The arguments are usual and in a way recall the discussions ​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"​.+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.
leading-edge_java_a_conversation_with_erich_gamma.1391761031.txt.gz · Last modified: 2017/09/06 01:54 (external edit)