design patterns - eth zfose.ethz.ch/slides/gamma.pdf · major contribution is communication of...
TRANSCRIPT
Design Patterns
3
outline
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.com 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 others 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-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
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"/>
org/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
outline
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
OOPSLA 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
outline
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 open-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