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

Design Patterns

2

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

3

• utline
• past
• patterns in action
• patterns today
• next

4

a fifteen year old thought experiment

imagine that you are struggling with a difficult software design problem

• you have spent days on the problem
• there was no obvious answer

... and find the answer in The Software Architecture Handbook

• presents design problems, issues, and solutions in a commonly

understood and shared language

• captures experience and expertise of designers
• provides a common and agreed position of what constitutes good and

bad design

• what should such a handbook contain and not contain?
• Who would use it? How would they use it?
• how could readers can best absorb the content and put into it into

practice? but raises some interesting questions about what it might look like

…in frustration and desperation you reach up to your bookshelf or google .... unfortunately the handbook does not exist

See also http://www.handbookofsoftwarearchitecture.com created by Grady Booch

5

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.

6

clues from other disciplines

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

7

capturing and describing good design

A Pattern is a way to capture recurring designs in such a way that

• thers can readily acquire and use the knowledge and experience

extracts essence of design

• provides freedom to adapt to particular context

describe commonly recurring designs

• captures commonly occurring solutions to

problems that occur again and again

• helps avoid design déjà vu

not just descriptive

• provides guidelines when to use and when not
• captures “why” decisions, design alternatives,

rationale

• provides design alternatives and describes

relative merits and trade-offs

• provides implementation hints

Design Patterns

grounded in real practice

8

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

9

early steps - recurring patterns in object-

• riented 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

10

eclipse

• introduced
• pattern variations
• XML based configuration
• extension points, lazy loading
• API focus
• evolution patterns

11

eclipse pattern variations

<action toolbarPath=“search" icon="icons/opentype.gif“ toolTip=“Open Type” class="org.eclipse.jdt.OpenTypeAction"/>

• rg/eclipse/jdt/OpenTypeAction.class

contribution implementation lazily instantiated using reflection

plugin.xml

• XML based configuration for extending the system

12

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

13

API evolution patterns

• compatibility layer
• I*2 extensions interfaces
• extension object pattern: IAdaptable

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 }

14

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>

15

JUnit

• A simple framework
• Design pattern dense
• Simplified using annotation/attribute based

programming

Pluggable Adapter TestCase run(TestResult) runTest() setUp() tearDown() fName Test run(TestResult) TestSuite run(TestResult) addTest(Test) fTests TestResult Template Method Command Composite: Leaf Composite:Component Composite Collecting Parameter

• thinned framework for the

client (inspiration from NUnit)

• “replaced” inheritance with

annotations

MoneyTest setUp() testSimpleAdd() testMixedAdd() MoneyTest @Before setUp() @Test simpleAdd() @Test mixedAdd()

JUnit3 JUnit4

JUnit3 ⇒ JUnit4

Command

17

• utline
• past
• patterns in action
• patterns today
• next

18

scope of patterns has broadened

Source: Amazon,com, Hillside.net

Software Design Architecture Buildings & Architecture Programming System Design Project Management, Organisation Organisation Requirements Analysis 90's 2000's Conferences J2EE, .NET 70's 80's Real-time, Embedded

OOPSL A BOF

Today

Topics

ECOOP

16 years of growth

19

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

20

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

21

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

22

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

23

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!

24

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?

25

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

26

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!!

27

• utline
• past
• patterns in action
• patterns today
• next

28

a lot has changed since design patterns…

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

29

what hasn’t changed

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

30

a new categorization

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

the patterns the students should learn lean on demand

31

new pattern members

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

32

current assignment: Jazz - integrating tools and their data

33

traditional tools integration

34

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?

35

REST principles

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

36

Open Services for Lifecycle Collaboration

 Community Driven – specified at

• pen-services.net

 Specifications for ALM Interoperability  Inspired by Internet architecture

• Loosely coupled integration with “just

enough” standardization

• Common resource formats and services

 A different approach to industry-wide proliferation

Open Services for Lifecycle Collaboration

Barriers to sharing resources and assets across the software lifecycle

 Multiple vendors, open source projects and in-house tools  Private vocabularies, formats and stores  Entanglement of tools with their data

Aimed at simplifying tool integration across the software lifecycle

37

“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.

38

linked lifecycle data

39

establishing links

Quality Manager Test Case Test Case & Plan item are linked in both directions Dialog for interacting with Rational Team Concert Click to add Plan- item Links Quality Manager Test Case Dialog for interacting with Rational Team Concert Click to add Plan- item Links Quality Manager Test Case Dialog for interacting with Rational Team Concert Test Case & Plan item are linked in both directions Click to add Plan- item Links Quality Manager Test Case Dialog for interacting with Rational Team Concert

40 40

link rendering and previews

41

eclipse vs. jazz integration architecture

• Eclipse
• a tools platform to implement

new tools

• Java APIs – single

implementation language

• patterns
• XML based configuration
• lazy creation
• Fine grained integration
• Jazz integration architecture
• Integrate existing tools
• specified protocols -> many languages
• patterns – REST with
• service documents, services
• discovery, factory URLs
• Coarse grained integration

42

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

43

summary: it is all about avoiding this…

Library dependencies – Taligent CommonPoint

44

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