Agenda • Introduction
• A first example
• Pattern description form
• Back to the example (the State pattern)
• Conclusion2
Software Design is Hard
• Especially for in inexperienced designers.
• Designing good-quality reusable software is even harder.
• Software design experience is difficult to communicate.
4
Becoming a Chess Master• First learn rules and physical requirements:
• e.g., names of pieces, legal movements, chess board geometry and orientation, etc.
• Then learn principles:
• e.g., relative value of certain pieces, strategic value of center squares, power of a threat, etc.
• However, to become a master of chess, one must study the games of other masters:
• These games contain patterns that must be understood, memorized, and applied repeatedly
• There are hundreds of these patterns.
[Levine and Schmidt]5
Becoming a Software Design Master
• First learn the rules:
• e.g., the algorithms, data structures, and languages of software
• Then learn the principles:
• e.g., structured programming, modular programming, object oriented programming, generic programming, etc.
• However, to truly master software design, one must study the designs of other masters:
• These designs contain patterns that must be understood, memorized, and applied repeatedly.
• There are hundreds of these patterns.
6 [Levine and Schmidt]
Talking like a Chess Master
• When a chess master describes a particular position in a game, he does not give the position of all pieces.
• Instead, he refers to a known game:
• We had the same opening as the 6th game of Fischer vs Spassky in 1972, but in move 11 I placed my tower in b1 instead of c1.
• There are hundred of known games.
7
Game 6 : Fischer - Spassky. After 38.Rf5-f6(xN)
Talking like a Software Design Master
• When designers discuss about software, they do not describe classes, attributes, types, and methods.
• Instead, they refer to known patterns:
• e.g., in JUnit, a Test Case is a Command and a Test Suite a Composite.
8
http://junit.org/
Motivation
• How to catalog design solutions, only known by expert designers?
• And above all, how to make them accessible to inexperienced designers?
• Catalog proven design solution and describe them as patterns.
9
A Little History (1/5)• Christopher Alexander:
• Notes on the Synthesis of Form, Harvard University Press, 1964.
• Oregon Experiment, Oxford University Press, 1975.
• A Pattern Language: Towns, Buildings}, Construction, Oxford University Press, 1977.
• Timeless Way of Building, Oxford University Press, 1979.10
History (2/5)• In [TTWoB] Alexander proposes an architecture
paradigm, based on three concepts:
• The Quality (a.k.a. ``the Quality Without a Name'').
• The Gate.
• The Way (a.k.a. ``the Timeless Way'').11
History (3/5)
• Using Pattern Languages for Object-Oriented Programs. Ward Cunningham and Kent Beck. OOPSLA'87.
12
History (4/5)
• Advanced C++ Programming Styles and Idioms. Jim Coplien, 1991.
• Workshops OOPSLA de 90 à 92.
13
History (5/5)
• Hillside Group (Conférences PLoP): Kent Beck, Grady Booch,
• Richard Gabriel et al. OOPSLA 1993, 94.
• Design Patterns [GoF]. 1995.
14
Pattern Definition• General definition:
• “A pattern is a general reusable solution to a commonly occurring problem within a given context.”
• Christopher Alexander:
• “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.”
15
TCP/IP Protocol Implementation
TCP/IP
open()close() send() acknowledge() synchronize()
status : String
TCP/IP::send(s : Stream) { if state = ‘opened’ { (…) } if state = ‘closed’ { (…) } if state = ‘idle’ { (…) } }
17
In Other Words
TCP/IP TCP/IP State
open()
Close
open()
Open
open()
open()close() send() acknowledge() synchronize()
state
Idle
open()
20
Consequences
• Each instance of « TCP/IP » is linked to an instance of a subclass of « TCP/IP State »
• State verification is no longer necessary.
23
Observations• This solution is used on several TCP/IP protocol
implementations.
• A similar solution is used on several drawing programs (tool behavior according to the selected figure).
«abstract»DrawingContext dragAndDrop(Point, Point)
«abstract»SelectionState
Line Selected Erase Selected
Pointer Selected
Rectangle Selected
Circle Selected
1 1
selection
24
Description Forms
• Patterns are not code, they are only “documentation”.
• A pattern is described in a specific literary form.
• There are different pattern description forms:
• Alexander, Coplien, GoF, Portland, Cockburn, etc.
26
Name
• A significant label that reflects the principle of the pattern.
• The name tends to be based on the solution.
• The name becomes part of the domain vocabulary (pattern language).
28
Context
• The context describes the place of the pattern in a system.
• It specifies programming languages, sizes, scope, performance, or anything else that, if changed, would invalidate the pattern.
29
Problem
• Usually the problem is presented as a question or as a statement.
• The first thing one looks.
• The understanding of the problem comes with an analysis of pattern forces.
30
Forces• Forces are the core of a pattern.
• Forces determine a problem is difficult: they describe the trade-offs that drive the solution.
• Once the designer understands the forces of a pattern, he also understands the soundness of the solution and why a simper solution is not well-adapted.
• Typically, forces are related to software quality factors: performance, maintainability, etc.
31
Solution
• Solutions equilibrate les forces.
• Solutions apply to the system as a whole: they are transformable and not fixed.
• Solutions are not unique: a single pattern can be applied several times and yet have different solutions.
• Solutions can be partially described as UML Collaboration.
32
Problem
• How to treat an object whose behavior is strongly dependent on its internal state, without checking this state at each operation call?
36
Context
• The object behavior depends on its state.
• Operations have large, multipart conditional statements that depend on the object's state.
37
Solution Collaboration Diagram
38
/request() [*]/Context
/handle() [*]/State
/handle() [*]/ConcreteState [*]
ConnectorClass Role
Class Role
Class Role
Method Role
Solution Class Diagram
open()
TCP/IP
State
open()
TCP/IP State
open()
Open
open()
Close
open()
Idle
context
state
Collaborat
ion Use
Forces1. State-specific behavior is isolated,
increasing maintainability.
2. Replacing a conditional by a delegation may reduce performance.
3. State transition become explicit, increasing testability.
4. State sub-instances may be shared by several contexts, if they do not contain properties.
5. Who defines the state transitions?
• The Context: less robust
• The States: the context must provide an appropriate interface and the states must know the context.
6. How to create and destroy states?
• When the context is created.
• Later (lazy instantiation).
7. Dynamic inheritance may be used in Self
40
Author and Date
• The State pattern is part of the GoF Catalog.
• It was applied to TCP connection protocols [Johnson and Zweig 91] and to graphical editors such as HotDraw [Johnson 92] and Unidraw [Vlissides and Linton 90].
41
Final Remarks• Patterns are micro-architecture, they cannot ensure a good
overall architecture.
• Patterns do not cover all design decisions: creativity is still needed!
• Do not be overly enthusiastic: patterns should not be used at all costs.
• Learning patters requires time. Do not be impatient.43
Conclusion
• Design patterns collect design knowledge and improve communication.
• There are hundred of design patterns available.
• Essential patterns: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Façade, Null Object.
44
References
• « Software Patterns ». James Coplien. SIGS Books. New York, 1996.
• « Smalltalk Patterns: Best Practices ». Kent Beck. Prentice Hall, 1997, 256 pp., ISBN 0-13-476904-X.
• « Design Patterns: Elements of Reusable Object-Oriented Software ». Erich Gamma, Richard Helm,Ralph Johnson, and John Vlissides. Addison Wesley. October 1994.
45
References
• The « Pattern Languages of Program Design » series:
• Coplien & Schmidt
• Vlissides, Coplien, & Kerth
• Martin, Riehle, Buschmann
• Harrison, Foote, Rohnert46
References
• “Introduction to Patterns and Frameworks”. Dr. David L. Levine and Douglas C. Schmidt. Department of Computer Science Washington University, St. Louis.
47
Web Sites• Patterns homepage:
http://hillside.net/patterns/
• Portland Pattern repository: http://c2.com/ppr/index.html
• Cetus Links: http://www.objenv.com/cetus/oo_patterns.html
• Patterns FAQ: http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
48