Design Patterns

Gerson Sunyé gerson.sunye@univ-nantes.fr

Plan

Introduction
A first example
Pattern description form
Back to the example (the State pattern)
Conclusion

Software Design is Hard

Especially for in inexperienced designers.
Designing good-quality reusable software is even harder.
Software design experience is difficult to communicate.

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!

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.

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.

Figure 1. Game 6 : Fischer - Spassky. After 38.Rf5-f6 (xN)

There are hundred of known games!

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.

Figure 2. Design Patterns in JUnit v3

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.

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.

The current use of the term "pattern" is derived from the writings of the architect Christopher Alexander who has written several books on the topic as it relates to urban planning and building architecture:

Although these books are ostensibly about architecture and urban planning, they are applicable to many other disciplines, including software development. In [Notes], Alexander argues that current architectural methods result in products that fail to meet the real demands and requirements of its users, society and its individuals, and are unsuccessful in fulfilling the quintessential purpose of all design and engineering endeavors: to improve the human condition. Alexander wanted to create structures that are good for people and have a positive influence on them by improving their comfort and their quality of life. He concluded that architects must constantly strive to produce work products that better fit and adapt to the needs of all their inhabitants and users and their respective communities. In [APL] Alexander describes some "timeless" design ideas to try and realize these goals.

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").

History (3/5)

Using Pattern Languages for Object-Oriented Programs. Ward Cunningham and Kent Beck. OOPSLA'87.

History (4/5)

Advanced C++ Programming Styles and Idioms. Jim Coplien, 1991.
Workshops OOPSLA de 90 à 92.

History (5/5)

Figure 3. Gang of Four Book

Hillside Group (PLoP Conferences): Kent Beck, Grady Booch,
Richard Gabriel et al. OOPSLA 1993, 94.
Design Patterns [GoF]. 1995.

Pattern Definition

A pattern is a general reusable solution to a commonly occurring problem within a given context.

— General definition

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

— Christopher Alexander

A First Example

The State pattern

TCP/IP Protocol Implementation

TCP/IP::send(s : Stream) {
if state = ‘opened’ {
		// (…)
	}
if state = ‘closed’ {
		// (…)
	}
if state = ‘idle’ {
		// (…)
	}
}

Problem

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

Solution

Isolate the behavior that depends on the connection states on different classes.

In other words

Connection Example (1/2)

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

Connection Example (2/2)

Consequences

Each instance of « TCP/IP » is linked to an instance of a subclass of « TCP/IP State »
State verification is no longer necessary.

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

Pattern Description Form

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.

Essential Parts

Name
Context
Problem
Forces
Solution
Author and Date

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

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.

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.

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 simpler solution is not well-adapted.
Typically, forces are related to software quality factors: performance, maintainability, etc.

Solutions

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.

Author and Date

The author of a pattern is seldom its creator.

Back to the Example

Name

State.
Alias: Objects for States, Envelope-Letter.

Problem

How to treat an object whose behavior is strongly dependent on its internal state, without checking this state at each operation call?

Context

The object behavior depends on its state.
Operations have large, multipart conditional statements that depend on the object’s state.

Solution

Figure 4. UML Collaboration Diagram

Solution

Figure 5. UML Class Diagram

Forces

State-specific behavior is isolated, increasing maintainability.
Replacing a conditional by a delegation may reduce performance.
State transition become explicit, increasing testability.

Implementation trade-offs

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.

How to create and destroy states?

When the context is created.
Later (lazy instantiation).
Dynamic inheritance may be used in Self

Implementation trade-offs (Cont.)

State sub-instances may be shared by several contexts, if they do not contain properties.

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

Conclusion

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 patterns requires time. Do not be impatient.

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.

References (1/3)

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

References (2/3)

The « Pattern Languages of Program Design » series:

Coplien & Schmidt
Vlissides, Coplien, & Kerth
Martin, Riehle, Buschmann
Harrison, Foote, Rohnert

References (3/3)

«Introduction to Patterns and Frameworks.» Dr. David L. Levine and Douglas C. Schmidt. Department of Computer Science Washington University, St. Louis.

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
Pattern repository with source examples (in French): https://github.com/ace-lectures/pattern-repository