Design Patterns

Gerson SunyéUniversity of Nantes

gerson.sunye@univ-nantes.frhttp://sunye.free.fr

1

Agenda • Introduction

• A first example

• Pattern description form

• Back to the example (the State pattern)

• Conclusion2

Introduction

3

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

A First ExampleThe State pattern

16

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

Problem

• How to avoid a connexion state verification each time a packet is sent?

18

Solution

• Isolate the behavior that depends on the connexion states on different classes.

19

In Other Words

TCP/IP TCP/IP State

open()

Close

open()

Open

open()

open()close() send() acknowledge() synchronize()

state

Idle

open()

20

Connexion Example

: TCP/IP :Close2 - open()1 - open()

TCP/IP::open() { this.status.open(); }

21

Connexion Example

: TCP/IP : Close

: Open

3 - delete link

4 - new link

22

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

Pattern Description Form

25

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

Essential Parts• Name

• Context

• Problem

• Forces

• Solution

• Author and Date27

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

Author and Date

• The author of a pattern is seldom its creator.

33

Back to the Example

34

Name

• State.

• Alias: Objects for States, Enveloppe-Letter.

35

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

Conclusion

42

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