Design Patterns Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich [email protected]

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 ... and find the answer in understood and shared language 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 the world. 5 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

describe • captures commonly occurring solutions to commonly problems that occur again and again recurring designs • helps avoid design déjà vu • provides guidelines when to use and when not grounded in real practice • captures “why” decisions, design alternatives, rationale • provides design alternatives and describes not just descriptive relative merits and trade-offs • provides implementation hints

extracts essence of design • provides freedom to adapt to particular context

A Pattern is a way to capture recurring designs in such a way that 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

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

…

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

Template Method run(TestResult) run(TestResult)  “replaced” inheritance with fTests runTest() addTest(Test) setUp() annotations TestResult tearDown() Composite: Leaf

Collecting Parameter fName Pluggable Adapter

MoneyTest MoneyTest Command

@Before setUp() setUp() @Test simpleAdd() testSimpleAdd() @Test mixedAdd() testMixedAdd() JUnit3 JUnit4 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

OOPSL ECOOP Software Design A BOF Architecture System Design

Programming

Conferences

J2EE, .NET

Organisation

Real-time, Embedded

Project Management, Organisation

Source: Amazon,com, Hillside.net 16 years of growth 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 major. include contribution coding is communication details, support of commonly many variations 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 feedback: “voting off the island”

. OOPSLA workshop 2004*: people voted on the patterns to indicate which ones they felt needed deletion in the current form . four patterns were voted off . Factory Method – confusion with Factory . Bridge . Flyweight . Interpreter . reason: people felt they were sufficiently uncommon . split decisions . Singleton . Chain of Responsibility

* http://martinfowler.com/bliki/OOPSLA2004.html

25 feedback

“while the book is still essential reading for anyone in the OO space, there's much that could be done to modernize it”

-- Martin Fowler

“there is more to both OO design and patterns than is achieved or intended by the Gang of Four” -- Frank Buschmann, Kevlin Henney “Beyond the Gang of Four”

I totally agree!!

26 outline

. past . patterns in action . patterns today . next

27 a lot has changed since design patterns…

. the Web . Java, C# . XML . RDF . UML . refactoring aware tools . Open Source . annotation/attribute based programming

28 what hasn’t changed

. object-oriented design principles . most of the patterns . the importance of decoupling and cohasion

29 a new categorization

. Core . Creational . Composite . Factory method . Strategy . Prototype . State . Builder . Command . . Iterator . Peripheral . Proxy . Abstract Factory (peripheral) . Template Method . Memento . Facade . Chain of responsibility . Null Object . Bridge . Visitor . Type Object . Decorator . Mediator . Singleton . Extension Objects . Other (Compound) . Interpreter . Flyweight

the patterns the students lean on should learn demand 30 new pattern members

. Type Object . Null Object . Extension Object Interface . Value Object . Dependency Injection

31 current assignment: Jazz - integrating tools and their data

32 traditional tools integration

33 the Web as a design inspiration

. patterns emerged before the Web . the Web has changed the way how we produce and share information

. the Web is a success story for a scalable distributed system . what are the guiding principles that make it successful? . what technologies and can and should we use to build such systems?

34 REST principles

. Step 1: URLs for resources . Step 2: specified resource formats . Step 3: specified resource services

35 Open Services for Lifecycle Collaboration Aimed at simplifying tool integration across the software lifecycle

Open Services for Lifecycle Collaboration

 Community Driven – specified at Barriers to sharing resources open-services.net and assets across the software lifecycle  Specifications for ALM Interoperability  Multiple vendors, open source  Inspired by Internet architecture projects and in-house tools . Loosely coupled integration with “just  Private vocabularies, formats enough” standardization and stores . Common resource formats and services  Entanglement of tools with their data  A different approach to industry-wide proliferation

36 “Linked Data”

. Linked Data is an approach, defined by Tim Berners-Lee, to data integration on the Web . http://www.w3.org/DesignIssues/LinkedData.html . Linked Data principles 1. Use URIs as names for things. 2. Use HTTP URIs so that people can look up those names. 3. When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL). 4. Include links to other URIs so that they can discover more things.

37 linked lifecycle data

38 establishing links

Quality Manager Test Case Dialog for interacting with Rational Team Concert

Click to add Plan- Test Case & Plan item Links item are linked in both directions

39 link rendering and previews

40 40 eclipse vs. jazz integration architecture

. Eclipse . Jazz integration architecture . a tools platform to implement . Integrate existing tools new tools

.Java APIs – single . specified protocols -> many languages implementation language

. patterns . patterns – REST with . XML based configuration . service documents, services . lazy creation . discovery, factory URLs

. Fine grained integration . Coarse grained integration

41 conclusion

. you cannot learn patterns from a book . no book can completely describe a pattern . it will never fully describe perfectly when the pattern is applicable . it will never tell you all you need to know to implement it . it will never tell you all the consequences of using the pattern.

. … but having a book is better than not having a book

learn from the Web how to build distributed systems

42 summary: it is all about avoiding this…

Library dependencies – Taligent CommonPoint 43 see it all live at Jazz.net . transparent development . Jazz architecture . Jazz products . self-hosting . Using Jazz products… . … to develop Jazz products

. learn about Jazz at Jazz.net . participate in the evolution . try it . sandbox available

• www.open-services.net 44