Design Patterns Erich Gamma IBM Distinguished Engineer IBM - PowerPoint PPT Presentation

Design Patterns

Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich erich_gamma@ch.ibm.com 2

outline  past  patterns in action  patterns today  next 3

a fifteen year old thought experiment imagine that you are struggling with a • you have spent days on the problem difficult software design • there was no obvious answer problem … in frustration and desperation you reach up to your bookshelf or google .... • presents design problems, issues, and solutions in a commonly understood and shared language ... and find the answer in The Software • captures experience and expertise of designers Architecture Handbook • provides a common and agreed position of what constitutes good and bad design unfortunately the handbook does not exist but raises some • what should such a handbook contain and not contain? interesting questions • Who would use it? How would they use it? about what it might look • how could readers can best absorb the content and put into it into like practice? See also http://www.handbookofsoftwarearchitecture.com created by Grady Booch 4

? towards the goal • http:// www.handbookofsoftwarearchitecture.co m initiated by Grady Booch The Handbook of Software Architecture is a concise reference on the design of software-intensive systems. Written for software architects, developers, and project managers, the Handbook presents the fundamentals of software architecture, covering contemporary best practices for specifying, visualizing, documenting, governing, and evolving a system's significant design decisions. The center of this work presents the as-built architecture of a variety of software- intensive systems selected from across the industry and from across 5 the world.

clues from other disciplines mechanical engineering furniture and timber architecture handbooks framing handbooks “I have drawn up definite rules to “Mechanisms of Modern "If you combine technique and enable you to have personal Engineering Design”: Ivan knowledge of the material, will knowledge of the quality both of Artobolevsky 1947 automatically design around the existing buildings and of those construction, and not construct which are yet to be constructed." around the design. ... as ... construction becomes second " A temple is called IN ANTIS, nature when you are designing." when it has antæ or pilasters in front of the walls which Tage Frid enclose ... " Marcus Vitruvius Pollio “ De Architectura Libri Decem " 27 BC 6

capturing and describing good design • captures commonly occurring solutions to describe problems that occur again and again commonly recurring designs • helps avoid design déjà vu • provides guidelines when to use and when not grounded in real • captures “why” decisions, design alternatives, practice rationale • provides design alternatives and describes relative merits and trade-offs not just descriptive • provides implementation hints extracts • provides freedom to adapt to particular context essence of design A Pattern is a way to capture recurring designs in such a way that Design Patterns others can readily acquire and use the knowledge and experience 7

a design patterns inspiration  The iPhone SDK is based on the NeXTStep object-oriented frameworks  Existed before we wrote Design Patterns 15 years ago  Source of inspiration for several design pattern variations for: Adapter , Bridge , Proxy , Observer and Chain of Responsibility  good design survives 8

early steps - recurring patterns in object- oriented designs Initial Focus on Object Oriented Design First dozen of patterns reverse architected from ET++ (91) Jim Coplien ’ s catalog of C++ idioms (91) John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma get together between (90-92) to write Design Patterns • Smalltalk, C++ focus • first version of catalog • 23 pages long • only experts understand it: • “ oh, I ’ ve done that ” • Inspirations from Smalltalk, InterViews, NeXTStep, ET++ Design Patterns published October 1994 9

eclipse  introduced  pattern variations  XML based configuration  extension points, lazy loading  API focus  evolution patterns 10

eclipse pattern variations  XML based configuration for extending the system plugin.xml <action toolbarPath= “ search" icon="icons/opentype.gif “ toolTip= “ Open Type ” class="org.eclipse.jdt.OpenTypeAction"/> lazily instantiated using reflection org/eclipse/jdt/OpenTypeAction.class contribution implementation 11

APIs first  APIs don ’ t just happen; we need to design them  specifications with precisely defined behavior  what you can assume (and what you cannot)  it works ≠ API compliant  documented classes ≠ API  must have at least one client involved, preferably more 12

API evolution patterns  compatibility layer  I*2 extensions interfaces public interface IActionDelegate { … } // original interface public interface IActionDelegate2 extends IActionDelegate { void dispose (); } if (d instanceof IActionDelegate2) { IActionDelegate2 d2 = (IActionDelegate2) d; d2. dispose (); // call new method }  extension object pattern: IAdaptable 13

Extension Object Pattern: IAdaptable  adding interfaces to existing types  Interface negotiation <extension point=" org.eclipse.core.runtime.adapters "> < factory class ="org.eclipse.jdt.internal.ui.JavaElementAdapterFactory" adaptableType ="org.eclipse.jdt.core.IJavaElement"> < adapter type ="org.eclipse.ui.IPersistableElement"/> … </factory> 14

JUnit  A simple framework  Design pattern dense  Simplified using annotation/attribute based programming 15

JUnit3 ⇒ JUnit4 Test Composite:Component run(TestResult)  thinned framework for the client (inspiration from NUnit) Command TestCase TestSuite Composite  “ replaced ” inheritance with Template Method run(TestResult) run(TestResult) fTests annotations runTest() addTest(Test) setUp() TestResult tearDown() Composite: Leaf Collecting Parameter Pluggable Adapter fName MoneyTest Command MoneyTest @ Before setUp() setUp() @ Test simpleAdd() testSimpleAdd() @ Test mixedAdd() testMixedAdd() JUnit4 JUnit3

outline  past  patterns in action  patterns today  next 17

scope of patterns has broadened 70's 80's 90's 2000's Today Topics Buildings & Architecture Requirements Analysis Software Design OOPSL ECOOP A BOF Architecture System Design Programming Conferences J2EE, .NET Organisation Real-time, Embedded Project Management, Organisation 16 years of growth Source: Amazon,com, Hillside.net 18

patterns today - useful, used, useable  useful - patterns enable to repeat a successful design done by someone else  between 'if-then-else" and layering, decoupling  a good pattern is convincing  non-obvious solution ⇒ surprise its users, experts “ I ’ ve done that ”  used - recurring phenomenon  used in discussions, in code and documentation to talk about design  APIs and libraries  usable  include coding details, support many variations major contribution is communication of commonly occurring design problems and solutions 19

patterns community  the active pattern community was and is a key element to the success of patterns  the pattern community has its own culture  writer ’ s workshop  shepherding work  published as “ Pattern Languages of Program Design ”  9 regular conferences on 5 continents  ChiliPLoP, EuroPLoP, VikingPLoP, KoalaPLoP, SugarLoaf PLoP, …  5 volumes of “ pattern languages of program design ” ⇒ patterns continue to flourish ⇒ new leaders are emerging 20

patterns & design  refactor to patterns  patterns not measure of goodness  some patterns are cool, but this doesn't make them more relevant  patterns used for  variability management  decoupling  dependency management patterns a means to an end, not the end 21

patterns & complexity  each pattern makes a system a little bit more complex  software infrastructures are getting more and more complex …  using lots of unnecessary patterns makes a system so complex that it becomes unmanageable  this isn't the patterns fault … but … we have never discussed when to remove a pattern from a system 22

dangerous patterns  Mediator  supposed to be used to allow colleagues to be reusable  is often used to allow programmers to continue to be procedural.  Singleton  supposed to be used to encapsulate global state when it cannot be eliminated  is often used as a justification of global state  adding global state is easy – removing it hard! 23

what the students are saying about patterns  “ we had them all … ”  Erich Gamma is considered the enemy by many CS students  patterns are supposed to solve real software engineering problems (or something; what do I know?)  I spent most of the time trying to figure out what "Chocolate Factory" and various bizarre chocolate eating habits that border on obsessive-compulsive disorder had to do with the Abstract Factory and Singleton design patterns have we solved how to teach patterns? 24