Main Pattern-oriented software architecture, vol.5: on patterns and pattern languages

Pattern-oriented software architecture, vol.5: on patterns and pattern languages

, ,
0 / 0
How much do you like this book?
What’s the quality of the file?
Download the book for quality assessment
What’s the quality of the downloaded files?
Software patterns have revolutionalized the way developers think about how software is designed, built and documented. This book offers an in-depth look at what patterns are, what they are not, and how to use them successfully. Foreword by Richard P. Gabriel. Foreword by Wayne Cool. About the Authors. About this Book. Guide to the Reader. Beyond the Hype. Beginnings'. A Story of Success - with Some Exceptions. Pattern Definitions and their Interpretations. Toward a Deeper Understanding of Patterns. PART I: INSIDE PATTERNS. 1. A solution to a Problem and More. 1.1 A Solution to a Problem. 1.2 A Process and a Thing. 1.3 Best of Breed. 1.4 Forces: the Heart of Every Pattern. 1.5 The Context: Part of a Pattern or Not? 1.6 Genericity. 1.7 A Diagram Says More than a Thousand Words? or Less. 1.8 Evocative Names Help Pattern Recollection. 1.9 Patterns are Works in Progress. 1.10 A Pattern Tells a Story and Initiates a Dialog. 1.11 A Pattern Celebrates Human Intelligence. 1.12 From a Problem-Solution Statement to a Pattern. 2. A Million Different Implementations. 2.1 Does One Size Fit All? 2.2 Patterns and Frameworks. 2.3 Patterns and Formalisms. 2.4 A Million and One? and then Some. 3. Notes on Pattern Form. 3.1 Style and Substance. 3.2 The Function of Form. 3.3 Elements of Form. 3.4 Details, Details. 3.5 Aerial View. 3.6 Different Pattern Forms. 3.7 Style and Substance (Redux). PART II: BETWEEN PATTERNS. 4. Pattern Islands? 4.1 Patterns Connect. 4.2 A Design Experiment: Patterns as Islands. 4.3 A Second Design Experiment: Interwoven Patterns. 4.4 Pattern Density. 5. Pattern Complements. 5.1 More than One Solution to a Problem. 5.2 Patterns in Competition. 5.3 Patterns in Cooperation. 5.4 Patterns in Combination. 5.5 Complementary: Competing, Completing, Combining. 6. Pattern Compounds. 6.1 Recurring Pattern Arrangements. 6.2 From Elements to Compounds. 6.3 From Complements to Compounds. 6.4 Element or Compound? 6.5 Compound Analysis and Synthesis. 7. Pattern Sequences. 7.1 Patterns Tell Software Engineering Success Stories. 7.2 Pattern Stories. 7.3 From Stories to Sequences. 7.4 Sequences of Patterns. 7.5 Pattern Compounds and Complements Revisited. 7.6 Returning to the Question of Context. 7.7 Pattern Connections. 8. Pattern Collections. 8.1 Toward a Handbook. 8.2 Organizing Pattern Collections. 8.3 Ad Hoc Organization. 8.4 Organization by Level. 8.5 Organization by Domain. 8.6 Organization by Partition. 8.7 Organization by Intent. 8.8 Organizing Pattern Collections (Reprise). 8.9 Problem Frames. 8.10 Pattern Semiotics. 8.11 Pattern Collections and Style. 8.12 Toward Pattern Languages. Part III Into Pattern Languages. 9. Elements of Language. 9.1 Designing with Patterns. 9.2 From Pattern Stories and Sequences to Pattern Languages. 10. A Network of Patterns and More. 10.1 A Network of Patterns. 10.2 A Process and a Thing. 10.3 Best of Breed. 10.4 Forces: the Heart of Every Pattern Language. 10.5 Pattern Contexts Define Topology and Architectural Style. 10.6 Patterns Form Vocabulary, Sequences Illustrate Grammar. 10.7 Genericity. 10.8 A Whole Language Says More than a Thousand Diagrams . 10.9 Domain-Oriented Names Help to Recall Pattern Languages. 10.10 A Pattern Language Initiates Dialog and Tells Many Stories. 10.11 Work in Progress. 10.12 Pattern Languages Reward Creative Human Intelligence. 10.13 From a Pattern Network to a Pattern Language. 11. A Billion Different Implementations. 11.1 One Size Does Not Fit All. 11.2 Piecemeal Growth. 11.3 Refactoring Not Excluded. 11.4 One Pattern at a Time. 11.5 Role-Based Pattern Integration. 11.6 Pattern Languages and Reference Architectures. 11.7 Pattern Languages and Product-Line Architectures. 11.8 A Billion and One? and then Some. 12. Notes on Pattern Language Form. 12.1 Style and Substance. 12.2 The Function of Form. 12.3 The Elements of Form. 12.4 Details, Details, Details. 12.5 Style and Substance (Redux). 13. On Patterns versus Pattern Languages. 13.1 Patterns and Pattern Languages: Similarities. 13.2 Patterns and Pattern Languages: Differences. 13.3 Patterns versus Pattern Languages? 14. From Patterns To People. 14.1 Patterns are for People. 14.2 In Support of Software Developers. 14.3 In Support of Software Users. 14.4 In Support of Pattern Authors. 14.5 Technology for Humans. 15. The Past, Presence, And Future of Patterns. 15.1 The Past Three Years at a Glance. 15.2 Where Patterns Are Now. 15.3 Where Will Patterns Go Tomorrow? 15.4 A Brief Note about the Future of Patterns. 16. All Good Things? Afterword. Pattern Concept Summary. Referenced Patterns. References. Index of Patterns. Index of Names. Index
Year:
2007
Publisher:
John Wiley
Language:
english
Pages:
491
ISBN 10:
0471486485
ISBN 13:
9780471486480
Series:
Wiley series in software design patterns
File:
PDF, 4.59 MB
Download (pdf, 4.59 MB)

You may be interested in Powered by Rec2Me

 
0 comments
 

You can write a book review and share your experiences. Other readers will always be interested in your opinion of the books you've read. Whether you've loved the book or not, if you give your honest and detailed thoughts then people will find new books that are right for them.
1

Implementations of PROLOG

ปี:
1984
ภาษา:
english
ไฟล์:
DJVU, 3.54 MB
0 / 0
ffirs.fm Page i Wednesday, March 21, 2007 11:14 AM

PATTERN-ORIENTED
SOFTWARE
ARCHITECTURE

ffirs.fm Page ii Wednesday, March 21, 2007 11:14 AM

ffirs.fm Page iii Wednesday, March 21, 2007 11:14 AM

PATTERN-ORIENTED
SOFTWARE
ARCHITECTURE
On Patterns and Pattern Languages

Volume 5

Frank Buschmann,
Siemens, Munich, Germany
Kevlin Henney,
Curbralan, Bristol, UK
Douglas C. Schmidt,
Vanderbilt University, Tennessee, USA

ffirs.fm Page iv Wednesday, March 21, 2007 11:14 AM

Copyright © 2007

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester,
West Sussex PO19 8SQ, England
Telephone

(+44) 1243 779777

Email (for orders and customer service enquiries): cs-books@wiley.co.uk
Visit our Home Page on www.wiley.com
All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in
any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under
the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright
Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the
Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd,
The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to permreq@wiley.co.uk, or
faxed to (+44) 1243 770620.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names
and product names used in this book are trade names, service marks, trademarks or registered trademarks of
their respective owners. The Publisher is not associated with any product or vendor mentioned in this book.
This publication is designed to provide accurate and authoritative information in regard to the subject matter
covered. It is sold on the understanding that the Publisher is not engaged in rendering professional services. If
professional advice or other expert assistance is required, th; e services of a competent professional should be sought.

Other Wiley Editorial Offices
John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA
Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA
Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany
John Wiley & Sons Australia Ltd, 42 McDougall Street, Milton, Queensland 4064, Australia
John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809
John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
available in electronic books.

British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
ISBN-13: 978-0-471-48648-0
Typeset in 10/13 Bookman-Light by Laserwords Private Limited, Chennai, India
Printed and bound in Great Britain by Antony Rowe Ltd, Chippenham, Wiltshire
This book is printed on acid-free paper responsibly manufactured from sustainable forestry
in which at least two trees are planted for each one used for paper production.

ffirs.fm Page v Wednesday, March 21, 2007 11:14 AM

For Anna, Bebé†, and Martina
Frank Buschmann

For Carolyn, Stefan, and Yannick
Kevlin Henney

For Lori, Bronson, Mom, and Dad
Douglas C. Schmidt

For John
Frank Buschmann, Kevlin Henney, Douglas C. Schmidt

† Bebé, July 3, 1999

ffirs.fm Page vi Wednesday, March 21, 2007 11:14 AM

ftoc.fm Page vii Wednesday, March 21, 2007 11:12 AM

Table of Contents

Foreword by Richard P. Gabriel

.......

xiii

.............

xxiii

...................

xxix

.....................

xxxi

Foreword by Wayne Cool
About the Authors
About this Book

Guide to the Reader

..................

xxxvii

0
0.1
0.2
0.3
0.4

Beyond the Hype . . . . . . . . . . . . . . . . . . .
Beginnings… . . . . . . . . . . . . . . . . . . . . . . .
A Story of Success… with Some Exceptions
Pattern Definitions and their Interpretations
Toward a Deeper Understanding of Patterns

Part I

Inside Patterns . . . . . . . . . . . . . . . . . . . . . . . .

1
1.1
1.2
1.3
1.4
1.5
1.6

A Solution to a Problem and More .
A Solution to a Problem . . . . . . . . . .
A Process and a Thing . . . . . . . . . . .
Best of Breed . . . . . . . . . . . . . . . . . .
Forces: the Heart of Every Pattern . .
The Context: Part of a Pattern or Not?
Genericity
....................

.
.
.
.
.

.
.
.
.
.
.
..

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

....
....
....
...
....

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

1
2
3
8
19

25
.
.
.
.
.
.
.

29
30
32
34
36
42
47

ftoc.fm Page viii Wednesday, March 21, 2007 11:12 AM

viii

Contents

1.7
1.8
1.9
1.10
1.11
1.12

A Diagram Says More than a Thousand Words…
or Less . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evocative Names Help Pattern Recollection . . .
Patterns are Works in Progress . . . . . . . . . . . .
A Pattern Tells a Story and Initiates a Dialog . .
A Pattern Celebrates Human Intelligence . . . . .
From a Problem–Solution Statement to a
Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2
2.1
2.2
2.3
2.4

A Million Different Implementations
Does One Size Fit All? . . . . . . . . . . . .
Patterns and Frameworks . . . . . . . . .
Patterns and Formalisms
.........
A Million and One… and then Some
.

3
3.1
3.2
3.3
3.4
3.5
3.6
3.7

Notes on Pattern Form . .
Style and Substance . . . . .
The Function of Form . . . .
Elements of Form . . . . . . .
Details, Details . . . . . . . . .
Aerial View . . . . . . . . . . . .
Different Pattern Forms . . .
Style and Substance (Redux)

.
.
.
.
.

50
54
57
61
62

.

63

.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

65
66
77
84
87

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

91
92
96
97
102
106
110
116

Part II

Between Patterns . . . . . . . . . . . . . . . . . . . . . .

117

4
4.1
4.2
4.3

Pattern Islands?
.................
Patterns Connect
.................
A Design Experiment: Patterns as Islands
A Second Design Experiment: Interwoven
Patterns
........................
Pattern Density . . . . . . . . . . . . . . . . . . .

......
......
.....

121
122
123

......
......

129
131

4.4

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

ftoc.fm Page ix Wednesday, March 21, 2007 11:12 AM

Contents

5
5.1
5.2
5.3
5.4
5.5

ix

Pattern Complements
............
More than One Solution to a Problem . .
Patterns in Competition . . . . . . . . . . . .
Patterns in Cooperation . . . . . . . . . . . .
Patterns in Combination
...........
Complementary: Competing, Completing,
Combining . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.

6
6.1
6.2
6.3
6.4
6.5

Pattern Compounds . . . . . . . . .
Recurring Pattern Arrangements
From Elements to Compounds . .
From Complements to Compounds
Element or Compound? . . . . . . .
Compound Analysis and Synthesis

.
.
.
.
.

135
136
138
155
159

.......

163

.
.
.
.
.
.

.
.
.
.
.
.

165
166
166
173
176
180

7
7.1

.....

183

.
.
.
.

.
.
.
.

184
185
191
192

7.6
7.7

Pattern Sequences . . . . . . . . . . . . . . . . .
Patterns Tell Software Engineering Success
Stories . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pattern Stories . . . . . . . . . . . . . . . . . . . . .
From Stories to Sequences . . . . . . . . . . . .
Sequences of Patterns . . . . . . . . . . . . . . .
Pattern Compounds and Complements
Revisited . . . . . . . . . . . . . . . . . . . . . . . . .
Returning to the Question of Context . . . .
Pattern Connections . . . . . . . . . . . . . . . . .

.....
.....
.....

197
203
207

8
8.1
8.2
8.3
8.4
8.5
8.6
8.7

Pattern Collections
......
Toward a Handbook . . . . . . .
Organizing Pattern Collections
Ad Hoc Organization
......
Organization by Level . . . . . .
Organization by Domain
...
Organization by Partition . . .
Organization by Intent . . . . .

.
.
.
.
.
.
.
.

209
210
211
212
213
218
219
221

7.2
7.3
7.4
7.5

...
...
..
...
...
...
...
...

....
....
....
..
....
..

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

ftoc.fm Page x Wednesday, March 21, 2007 11:12 AM

x

Contents

8.8
8.9
8.10
8.11
8.12

.
.
.
.
.

225
226
231
235
241

Part III Into Pattern Languages . . . . . . . . . . . . . . . . . .

243

9
9.1
9.2

Elements of Language . . . . . . . . . . . . . . . . . . .
Designing with Patterns
..................
From Pattern Stories and Sequences to Pattern
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

247
248

A Network of Patterns and More . . . . . . . . . .
A Network of Patterns . . . . . . . . . . . . . . . . . . .
A Process and a Thing . . . . . . . . . . . . . . . . . . .
Best of Breed . . . . . . . . . . . . . . . . . . . . . . . . . .
Forces: the Heart of Every Pattern Language . .
Pattern Contexts Define Topology and
Architectural Style
.....................
Patterns Form Vocabulary, Sequences Illustrate
Grammar
............................
Genericity . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Whole Language Says More than a Thousand
Diagrams
............................
Domain-Oriented Names Help to Recall Pattern
Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Pattern Language Initiates Dialog and Tells
Many Stories . . . . . . . . . . . . . . . . . . . . . . . . . .
Work in Progress . . . . . . . . . . . . . . . . . . . . . . .
Pattern Languages Reward Creative Human
Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.

259
260
260
269
273

.

277

.
.

280
285

.

287

.

288

.
.

290
291

.

293

10
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12

Organizing Pattern Collections
Problem Frames . . . . . . . . .
Pattern Semiotics . . . . . . . .
Pattern Collections and Style
Toward Pattern Languages
.

(Reprise)
........
........
........
........

.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

250

ftoc.fm Page xi Wednesday, March 21, 2007 11:12 AM

Contents

10.13

11
11.1
11.2
11.3
11.4
11.5
11.6

xi

From a Pattern Network to a Pattern
Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11.8

A Billion Different Implementations
One Size Does Not Fit All . . . . . . . . .
Piecemeal Growth
..............
Refactoring Not Excluded . . . . . . . . .
One Pattern at a Time
...........
Role-Based Pattern Integration . . . . .
Pattern Languages and Reference
Architectures . . . . . . . . . . . . . . . . . .
Pattern Languages and Product-Line
Architectures . . . . . . . . . . . . . . . . . .
A Billion and One… and then Some .

12
12.1
12.2
12.3
12.4
12.5

Notes on Pattern Language Form
Style and Substance
..........
The Function of Form . . . . . . . . . .
The Elements of Form
.........
Details, Details, Details . . . . . . . .
Style and Substance (Redux) . . . .

13
13.1
13.2
13.3
14
14.1
14.2
14.3
14.4
14.5

11.7

297
298
298
303
306
309

.........

315

.........
.........

317
322

.
.
.
.
.
.

.
.
.
.
.
.

..
.
.
..

.
.
.
.

.
.
.
.

347
348
351
354

From Patterns To People . . . . .
Patterns are for People . . . . . . . .
In Support of Software Developers
In Support of Software Users . . .
In Support of Pattern Authors . .
Technology for Humans . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

355
356
360
362
365
367

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

On Patterns versus Pattern Languages . .
Patterns and Pattern Languages: Similarities
Patterns and Pattern Languages: Differences
Patterns versus Pattern Languages? . . . . . .
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

325
326
326
328
334
346

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

...
...
..
...
...
...

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

295

.
.
.
.
.
.

ftoc.fm Page xii Wednesday, March 21, 2007 11:12 AM

xii

Contents

15
15.1
15.2
15.3
15.4

The Past, Presence, and Future of Patterns
The Past Three Years at a Glance
........
Where Patterns Are Now . . . . . . . . . . . . . . .
Where Will Patterns Go Tomorrow? . . . . . . .
A Brief Note about the Future of Patterns . .

.
.
.
.
.

369
370
375
376
384

16

All Good Things…

......................

385

Pattern Concept Summary

391

...................

397

..........................

415

Index of Patterns

......................

441

.......................

445

...............................

447

Index of Names
Index

.
.
.
.
.

..............

Referenced Patterns
References

.
.
.
.

fbetw.fm Page xiii Wednesday, March 21, 2007 11:14 AM

Foreword by Richard P. Gabriel

✝

‘Software patterns have significantly changed the way we design…’ is
how POSA5 starts out—its preface, its self-explanation, maybe its
justification. But design: what happens when we design? Is design
about problems or about beauty? Does resolving forces while solving
a problem force beauty into the design? Or can beauty and ideal problem solving emerge only after a (pattern) language has been tooled
over the raw material? Someone once told me that any establishment
where the entrance is obvious is not worth visiting.
The Oxford English Dictionary, second edition, informs us about design
as follows:
1. A mental plan.
1.a. a plan or scheme conceived in the mind and intended for subsequent execution;…the preliminary conception of an idea that is
to be carried into effect by action; a project;

In Guy Steele’s 1998 talk at OOPSLA, ‘Growing a Language,’ he said:
A design is a plan for how to build a thing. To design is to build a
thing in one’s mind but not yet in the real world—or, better yet, to
plan how the real thing can be built.

I once wrote:
Design is the thinking one does before building.

Carliss Baldwin and Kim B. Clark define design like this:
Designs are the instructions based on knowledge that turn
resources into things that people use and value.
—Between ‘Knowledge’ and ‘the Economy’: Notes on the Scientific Study of Designs

Each of these definitions and characterizations revolve around
ideas, plans, knowledge, problems, values and purposes, and hint
at a before-building time. Very rational-sounding and the way we
would like design to go—reliable, the trusty well-educated mind

fbetw.fm Page xiv Wednesday, March 21, 2007 11:14 AM

xiv

Foreword by Richard P. Gabriel

working things out: you can feel safe walking across the real thing
because it will not sway and fall down. But let’s think a little about
who we✝ is.
People have been ‘designing and building’ cities for millennia, using,
perhaps, tools and concepts like Christopher Alexander’s pattern
languages. Such artifacts are huge and hugely complex. It’s hard to
say where the mental plan is, because the imagining that might take
place is surely scattered across the years, decades, centuries, and
sometimes millennia it takes to fashion a proper city—a city like Athens, Rome, Berlin, London, Istanbul, or even New York or San Francisco and surely Boston. Thus the ‘we’ in the up-noted sentence✝
must refer to a more recent set of us-es—namely software designers,
who, one could argue, have gravitated toward the more conservative
or possibly less realistic ideas of design reflected in the quotes
above. Even in my quote—where I was trying to leave room for the
interweaving of design, building, and reflection that cities, for example, enjoy as part of their design journey—it is hard to not see the
before-building thrust into the forefront: the thinking one does before
building.
That design has a landscape of meanings and nuances brings to mind
a set of characterizations of design by Adrian Thompson at the University of Sussex. I call these characterizations design metaheuristics,
meaning they are approaches to how to think about design, like the
approach of using patterns and pattern languages. There are three
design metaheuristics. Here’s the first:
Inverse model is tractable: If there is a tractable ‘inverse model’
of the system, then there is a way of working out in advance a sequence of variations that brings about a desired set of objective
values.

Here a design is a plan, like a blueprint, and the inverse model is this:
once the thing to be designed is imagined, there is a way to work out
the blueprint or a plan for how to build the thing. This is the essential
up-front design situation, which works best when designing something that has been built at least once before, and typically dozens
or thousands of times. Alexander knows of this style of working: the
ideas behind patterns and pattern languages evolved from the notion that people who built, for example, Swiss barns knew Swiss-barn

fbetw.fm Page xv Wednesday, March 21, 2007 11:14 AM

Foreword by Richard P. Gabriel

xv

patterns and pattern languages naturally—as a result of seeing them
every day, working in them, and helping build them as children. In
this sense the inverse model is well established: the image in the
head is not unlike the barn next door, and the steps to build it are
known with perhaps only modest modification. A pattern language
(implicit or explicit) can guide the designer/builder along, and the little adjustments that are always needed are just building as usual.
This leads to Thompson’s second design metaheuristic:
Inverse model is not tractable, but forward model is: In this
case, we can predict the influence of variations upon the objective
values, but the system is not tractably invertible so we cannot derive in advance a sequence of variations to bring about a desired
set of objective values. This implies an iterative approach, where
variations carefully selected according to the forward model are
applied in sequence. This kind of iterative design-and-test is a
common component of traditional approaches.

Design a little, build a little, reflect a little—this is how I explain this
heuristic. It is the essence behind the agile methodologies, I think,
evolutionary design/programming, and Alexander’s ‘Fundamental
Process.’ From the Agile Manifesto:
Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to [sic] the shorter timescale.
…
The best architectures, requirements, and designs emerge from
self-organizing teams.
—http://agilemanifesto.org/principles.html

Alexander’s ‘Fundamental Process’ is how he describes designing and
building in The Nature of Order. In this massive four-volume book, he
talks about how centers—places of interest and attention in space—
are structured to create wholeness. Here are steps 1, 2, 4, 6, and 8:
1. At every step of the process—whether conceiving, designing,
making, maintaining, or repairing—we must always be concerned
with the whole within which we are making anything. We look at
this wholeness, absorb it, try to feel its deep structure.

fbetw.fm Page xvi Wednesday, March 21, 2007 11:14 AM

xvi

Foreword by Richard P. Gabriel
2. We ask which kind of thing we can do next that will do the most
to give this wholeness the most positive increase of life.
4. As we work to enhance this new living center, we do it in such
a way as also to create or intensify (by the same action) the life of
some larger center.
6. We check to see if what we have done has truly increased the
life and feeling of the whole. If the feeling of the whole has not been
deepened by the step we have just taken, we wipe it out. Otherwise
we go on.
8. We stop altogether when there is no further step we can take
that intensifies the feeling of the whole.

Pattern languages are used like this, both by Alexander and by software developers. Such usage reflects, merely, the realization that the
first design metaheuristic applies only to cases in which designs are
being (mostly) repeated. In such cases, there are often models that
can be used to simulate the design-a-little / build-a-little pattern the
‘Fundamental Process’ describes. Either there is literally a model—
physics and mathematics and science—that is the boss of the design,
and pretend designs can be tried out, or else we fool ourselves into
thinking that large steps in the fundamental process—releases of version 1, then version 2, then version 3—are each actually full-blown
designs. We are fooled because we don’t want to zoom out to the larger
scale. Alexander’s ‘Fundamental Process’ is also a good description of
the various agile methodologies, although one would expect refactoring to be more explicitly mentioned.
The book you either are about to read, are reading, or have finished
reading—the one in which this foreword is embedded—is about pattern languages largely in this context. The thinking one does before
building can be described by steps 1, 2, & 4. In this context, design
really is a sort of problem solving. As Jim Coplien says:
Design is a process of intentional acts to the end of moving from
some conception of a problem to the reduction of that problem. A
problem is the difference between a current state and desired
state.

This seems to miss two aspects that seem (to some) central to design: beauty and newness. A very fine wine glass is both functional
and beautiful, it is made from an exquisite and exotic material, its

fbetw.fm Page xvii Wednesday, March 21, 2007 11:14 AM

Foreword by Richard P. Gabriel

xvii

shape—each type of wine has a preferred wineglass shape to concentrate the aroma best, to direct the wine to the best part of the mouth
for its flavor components, to prevent too much warming from the
hands—presents the wine to its best effect, while also pleasing the
eye with its elegance and line. Instead of ‘newness’ I almost wrote
‘novelty,’ but ‘novelty’ implies an intellectual or academic newness
that misses the point. It isn’t that the design is an invention full of
brand new workings, it’s the pleasure and surprise of seeing something you've never seen before. I’m thinking about the Cord Model
810 automobile introduced in 1936:
The body design of the Cord 810 was the work of designer Gordon
M. Buehrig and his team of stylists that included young Vince
Gardner. The new car caused a sensation at the 1936 New York
Auto Show in November. The crowds around the 810 were so
dense, attendees stood on the bumpers of nearby cars to get a
look. Many orders were taken at the show…
—Wikipedia

People had never seen a car like this before—coffin-shaped nose, headlights hidden, exhaustpipes (one per cylinder) chromesnakes jutting
out the sides, the smooth curved shelf at the front—it even was
designed by stylists not designers. Notable about both its appearance,
engineering, and user experience were the recessed headlights and the
fact that the transmission came out the front of the engine, so that the
floor of the passenger compartment could be lower and flatter than was
usual at the time. Some say the design of the Cord 810 remains the
most distinctive of the twentieth century. In 1996, American Heritage
magazine proclaimed the Cord 810 sedan ‘ The Single Most Beautiful
American Car.’
For example.
I find it hard to say that the Cord is the result of the reduction of a
problem to a final outcome: something else is happening. Rebecca
Rikner names this ‘something else’:
Design is not about solving a problem. Design is about seeing the
beauty.

fbetw.fm Page xviii Wednesday, March 21, 2007 11:14 AM

xviii

Foreword by Richard P. Gabriel

Many would guess I’m done with Thompson’s metaheuristics, but
there’s a third. And it’s the third which is the topic of his research.
Neither forward nor inverse models are tractable: There is neither a way of discerning which variations will give improvements
in the objective values, nor a way of predicting what will be the effects of variations upon the objective values. Without evolution all
is lost.
—Notes on Design Through Artificial Evolution: Opportunities and Algorithms

Evolution!
Thompson’s work includes the design of an analog circuit that can
discriminate between 1kHz and 10kHz square waves using a fieldprogrammable gate array designed using a genetic algorithm.1 The
result is described as ‘probably the most bizarre, mysterious, and
unconventional unconstrained evolved circuit yet reported,’ in large
part because the researchers were unable, in the end, to understand
how the circuit works. It’s not important to understand the details of
the following remarks from their paper—just take a look at the expressions of incredulity:
Yet somehow, within 200ns of the end of the pulse, the circuit
‘knows’ how long it was, despite being completely inactive during
it.
This is hard to believe, so we have reinforced this finding through
many separate types of observation, and all agree that the circuit
is inactive during the pulse.

Research in genetic algorithms, genetic programming, neuro-evolution,
neural nets, and statistical/aleatoric methods all demonstrate surprising results—some of them displaying a puzzling illusion of design,
like the antenna designed and tested by NASA and designed by artificial evolution. The size of an infant’s hand, the elements bend off in a
crazy cryptosymmetry like a small black bush half-frozen after a frost.
It doesn’t look like something a person would design, but it has better
antenna-crucial characteristics in some ways, and so it is a good
design—in terms of reducing a problem.

1. Adrian Thompson et al, Explorations in Design Space: Unconventional Electronics
Design Through Artificial Evolution.

fbetw.fm Page xix Wednesday, March 21, 2007 11:14 AM

Foreword by Richard P. Gabriel

xix

But do we feel that it is a good design? What do we make of this evolution stuff? How does artificial evolution work? In short, a population
is subjected to artificial reproduction in which some characteristics
from one parent are combined with others from another. The resulting
characteristics are subjected to a small amount of random mutation,
and the resulting population—which can include the original parents
in some algorithms—is tested for fitness against a fitness function.
Assuming the characteristics are related to aspects of design, this
reduces to taking some design elements from one not-so-bad solution
and combining them with design elements from another not-so-bad
solution, making some small changes, and seeing how that goes.
Aside from the random part, this doesn’t sound so random.
If you take it from me that some of the things ‘designed’ this way have
interesting characteristics, we need to ask whether this approach is a
form of design. Some people would say that without a human designer, there can be no design, that the ‘intentional’ in Coplien’s characterization and the ‘mind’ in the OED definition are essential features.
Where are the ‘instructions based on knowledge’? If Pierre Menard2

2. Pierre Menard, Author of The Quixote, by Jorge Luis Borges. In this story, a twentieth
century writer (Menard) puts himself in a frame of mind to rewrite, word for word, part
of Cervantes’ Don Quixote de la Mancha, but not as a transcription, but as a coincidence. Enjoy:
It is a revelation to compare Menard’s Don Quixote with Cervantes’. The latter, for
example, wrote (part one, chapter nine):
…truth, whose mother is history, rival of time, depository of deeds, witness of
the past, exemplar and adviser to the present, and the future’s counselor.
Written in the seventeenth century, written by the ‘lay genius’ Cervantes, this
enumeration is a mere rhetorical praise of history.
Menard, on the other hand, writes:
.…truth, whose mother is history, rival of time, depository of deeds, witness
of the past, exemplar and adviser to the present, and the future’s counselor.
History, the mother of truth: the idea is astounding. Menard, a contemporary of
William James, does not define history as an inquiry into reality but as its origin.
Historical truth, for him, is not what has happened, it is what we judge to have
happened. The final phrases—exemplar and adviser to the present, and the
future’s counselor—are brazenly pragmatic.
The contrast in style is also vivid. The archaic style of Menard—quite foreign, after
all—suffers from a certain affectation. Not so that of his forerunner, who handles
with ease the current Spanish of his time.

fbetw.fm Page xx Wednesday, March 21, 2007 11:14 AM

xx

Foreword by Richard P. Gabriel

were to dream up the FPGA tone discriminator or the weird antenna,
such doubters might declare the result a design—or perhaps further,
human-sensible explanations of the design are required to make that
leap.
This brings to my mind the idea of canalization, described like this:
A developmental outcome is canalized when the developmental
process is bound to produce a particular end-state despite environmental fluctuations both in the development’s initial state and
during the course of development.
—(adapted from) Andre Ariew, Innateness is Canalization:
In Defense of a Developmental Account of Innateness

A thing produced is canalized when once it falls into a tributary of a river, by the process of its production it ends up in the river. ‘Canalized’
comes from the word ‘canal’—once in the canal, you cannot escape.
Strange attractors in complexity science are canalizations. Artificial
evolution doesn’t care whether a design—or at least a thing it produces—is beautiful, elegant, understandable, parsimonious, maintainable, extendable, sleek, slick, simple, superfluous, silly, or human. All
it cares about is that it fits what the fitness function dictates. The
design is not canalized by those things—those human things—as just
about all human designs are and most likely must be.
Facing it in another direction, the design of, say, the antenna looks
strange because it is not what a person would ever design. We are
incapable of exploring a full design space, only those parts that look
pretty to us.
This book is about design viewed through the lens of patterns and
pattern languages. As you read it, permit your mind to drift closer to
ideas of design and perhaps later on, further away. Permit yourself to
wonder about design in all its glories and incarnations. The three
design metaheuristics might very well represent points on a coherent
continuum, and if they do, there also is a point where the human
becomes non-human or, maybe worse, post-human.

fbetw.fm Page xxi Wednesday, March 21, 2007 11:14 AM

Foreword by Richard P. Gabriel

xxi

Pattern languages can encompass lots of design space. They are part
of our software design and construction toolboxes. They work by helping people design better. Reflection on good design is how pattern languages are written down. Design, design, design, design.
Richard P. Gabriel

fbetw.fm Page xxii Wednesday, March 21, 2007 11:14 AM

flast.fm Page xxiii Wednesday, March 21, 2007 11:13 AM

Foreword by Wayne Cool

Way back I fell in with a bunch hot on the trail of a revolution in programming, hefting on their backs the unwieldy and orthodoxless
ideas of a mad architect himself bent on revving the future by reviving
the past in the splendor of its design sense1 but not its design [Ale79].
This cool group holed up in retreats and self-concocted workshops,
never in a mainstream meet-up but in contrast to official miracles, in
a far-off locale, some backwater or Podunk which although unverifiable is visitable.2 Unlike the madman who crowed ‘beauty beauty
beauty,’ this crew worked the nuts, oiled the bolts, screwed together
a practice and a program, a practicality and a precision straightaimed at the practitioner and around the corner from theory.
Along the way I hopped from PLoP to PLoP, café to bar, beer to Starbucks; I was there when Beck proclaimed, when the workshops
wound up, when the rainstorm first came up on the parquet Allerton
floor, when the sun rose at Irsee, when the trail rides ended and the
dust settled in Wickenberg; I was there when the books were written,
reviewed, printed, and praised. Through all this I watched the interest
grow in design and the structure of man-made things, in the strength
of the written word aimed at the creation of a built-up world made of
ideas and abstractions but felt like the built world of wood and shellac, stone and metal rods.
And this is what I want to come to: the realm of software patterns
converts the world of surfaces—a world where mechanism is hidden
beneath impenetrable covers—to one of exposed innards and plain
working; the hidden becomes the object of a craftsmanship that can
be defined as the desire to do something well—for its own sake, for no
reward, for the pride of skill applied with discernment and in reflection, taking a long time and going deeply into it. For those who build
1. Or ‘scents,’ as the agile would proclaim.
2. Apologies to Bill Knott.

flast.fm Page xxiv Wednesday, March 21, 2007 11:13 AM

xxiv

Foreword by Wayne Cool

this way, it matters little that the craft is buried under a user interface—
because one day someone must peek underneath and see. The surfaces matter but they don’t hide.
Art. Craft. Engineering. Science. These are the swirling muses of
design patterns. Art and science are stories; craft and engineering are
actions.
Craft is midway between art and science; art and craft stand over
against engineering and science. Art is the unique example, the first
thing, the story as artifact condensing out of talent and desire. Craft
is reliable production of quality. A craftsman3 might be disappointed
but rarely fails. A work of craft is the product of a person and materials. Engineering is reliable and efficient production of things for the
use and convenience of people. Science is a process of making a story
that can be used for engineering. A book called ‘The Art of X’ is about
the mystery of the rare individual who can make an X. ‘ The Craft of
X’ is about the sweat and training endured by those who make Xs one
at a time. ‘The Engineering of X’ is about discipline and long days
planning and making Xs for institutional customers. ‘The Science of
X’ is a maths book.
But the roles of science and craft have been misdiagnosed. Most believe (deeply) that science precedes, as they believe it must, craft and
engineering; that building requires abstract knowing. As in: to design
a steam engine you need a (correct) theory of thermodynamics. But
when the steam engine was developed, scientists believed the ‘caloric
theory:’ that there is a ‘subtle fluid’ called caloric that is the substance
of heat. The quantity of this substance is fixed in the universe; it flows
from warmer bodies to colder. Good story. The caloric theory explained
a lot, but the mechanics who built the first steam engines didn’t know
the theory or didn’t care about it. Working with boilers, they noticed
relations between volume, pressure, and temperature and they built
steam engines. Maybe the scientists even used observations of steam
engines to come up with ‘modern’ thermodynamics.

3. Today I choose the pretty word.

flast.fm Page xxv Wednesday, March 21, 2007 11:13 AM

Foreword by Wayne Cool

xxv

Craftsmen know the ways of the substances they use. They watch.
Perception and systematic thinking combine to formulate understanding. A well-developed craft gives rise to technological developments. And science. Sure: there are feedback loops between science
and engineering, but neither is queen—and hands-on dominates sitand-think.
This is about building, and all building requires planning and execution. Planning is the thinking one does before building. Execution is
understanding the plan and producing something from it. Since the
early twentieth century management science has pushed for the separation of planning from execution. Frederick Winslow Taylor said it
with art and poetry this way:
All possible brain work should be removed from the shop and centered in the planning or lay-out department.
—Principles of Scientific Management

Sweet.
Planning and execution merge in art but stand wide apart in engineering; somewhere in between for craft. Science is in the realm of
thought and ideas.
Separation of planning from execution is not about efficiency. Not
about getting the most value per hour. Maybe it will; maybe it won’t.
Planning takes thinking; thinking costs money. If you can think a little,
build a lot, you can make money. Thinking while executing is replaced
by process; education is replaced by training—the way Dancing Links
and Algorithm X4 can solve Sudoku. With Dancing Links and Algorithm X, Sudoku needs a computer, not a person. Separating planning
from execution is about cost.
And this is not about quality. The best quality cars are not built on
blind robotic assembly lines. Cost.
If cost is pressure toward engineering, patterns is the push-back toward
craft and art.

4. Dancing Links is a technique suggested by Donald Knuth to efficiently implement
Algorithm X, a recursive, nondeterministic, depth-first, brute-force algorithm that
finds all solutions to the exact cover problem.

flast.fm Page xxvi Wednesday, March 21, 2007 11:13 AM

xxvi

Foreword by Wayne Cool

Patterns. Craftsmanship: we think of it arising from the texture of the
built world. A world where quality and attention to detail is visible on
the surface of materials, in the gaps between things, in methods of
joining without friction but with shape and convolution. A world where
talent sits besides knowledge and intelligence. Read this description of
the problem of making felloes—sections of rim on a wooden carriage
wheel—in The Wheelwright’s Shop by George Sturt:5
Yet it is in vain to go into details at this point; for when the simple
apparatus had all been gotten together for one simple-looking process, a never-ending series of variations was introduced by the
material. What though two felloes might seem much alike when
finished? It was the wheelwright himself who had to make them
so. He it was who hewed out that resemblance from quite dissimilar blocks, for no two felloe-blocks were ever alike. Knots here,
shakes6 there, rind-galls7, waney8 edges, thicknesses, thinnesses,
were for ever affording new chances or forbidding previous solutions, whereby a fresh problem confronted the workman’s ingenuity every few minutes. He had no band-saw (as now [1923]) to
drive, with ruthless unintelligence, through every resistance. The
timber was far from being prey, a helpless victim, to a machine.
Rather it would lend its own special virtues to the man who knew
how to humour it.
—The Wheelwright’s Shop

You can feel the wood as equal partner to craftsman.
The work of patterns is the work of people who have systematic encounters with code, going deeply into it, dwelling for long periods of time on
the tasks of design and coding to get them right, people who don’t believe planning can be separated from execution. People who work this
way are having the sort of encounter that gives rise to science. This is
not mere trafficking in abstractions; it is thinking. Patterns don’t push

5. First published in 1923.
6. A crack in timber caused by wind or frost.
7. A damage the tree received when young, so that the bark or rind grows in the inner
substance of the tree.
8. A sharp or uneven edge on a board that is cut from a log not perfectly squared, or
that is made in the process of squaring.

flast.fm Page xxvii Wednesday, March 21, 2007 11:13 AM

Foreword by Wayne Cool

xxvii

toward art and craft but are the tools of people who do. To be resisted
is the automation of patterns which is the separation of planning and
execution.
Computer scientists stand at the chalkboard—write and erase, squint
and stare, remark and declaim. Patterns people, like mechanics, bend
at the waist and peer into the code, their arms are drenched in code
up to the elbows. It’s what they work on: knots here, shakes there,
rind-galls, waney edges, thicknesses, thinnesses forever affording
new chances or forbidding previous solutions. They see programming
almost as manual work—muscled arms, sleeves rolled tight against
biceps, thought bright behind the eye linking mind and hand.

I was there when the patterns community started. I sat the hillside; I
huddled in the redwoods; I ran the beach; I hiked Mt Hood; I kayaked,
did the ropes course, gazed on the Sun Singer at sunset; I sweated in
the sauna; I rode the big horse, Bigfoot; I sang with the cowboy over
steaks and corn. But I didn’t add a single idea, not even one sentence,
nor one dot of punctuation to what the patterns people thought, wrote,
and built. I’ll bet, though, you know exactly what I think about it.
Wayne Cool, Venice Beach

flast.fm Page xxviii Wednesday, March 21, 2007 11:13 AM

flast.fm Page xxix Wednesday, March 21, 2007 11:13 AM

About the Authors

Frank Buschmann
Frank Buschmann is Senior Principal Engineer at Siemens Corporate
Technology in Munich, Germany. His research interests include
object technology, software architecture, product-lines, model-driven
software development, and patterns. He has published widely in all
these areas, most visibly in his co-authorship of three POSA volumes
[POSA1] [POSA2] [POSA4]. Frank was a member of the ANSI C++
standardization committee X3J16 from 1992 to 1996, initiated the
first EuroPLoP conference in 1996, co-edited several books on patterns [PLoPD3] [SFHBS06], and serves as an editor of the Wiley Series
in Software Design Patterns. In his development work at Siemens,
Frank has led architecture and implementation efforts for several
large-scale industrial software projects, including business information, industrial automation, and telecommunication systems.
When not at work Frank spends most of his time enjoying life with his
wife Martina and daughter Anna, having fun riding his horse Eddi,
watching the time go by in Munich beer gardens, getting excited when
watching his favorite soccer team, Borussia Dortmund, dreaming
when listening to a performance at the Munich opera, and relaxing
with rare Scotch single malts before bedtime.

Kevlin Henney
Kevlin Henney is an independent consultant based in Bristol, UK. His
work involves teaching, mentoring, and practicing across his areas of
interest, which include programming languages and techniques, software architecture, patterns, and agile development. His clients range
from global firms to smaller startups, involved in the worlds of systems software, telecommunications, embedded systems, middleware
development, business information, and finance.

flast.fm Page xxx Wednesday, March 21, 2007 11:13 AM

xxx

About the Authors

Kevlin is a regular speaker at software conferences, and has also been
involved with the organization of many conferences, including EuroPLoP. He has participated in the C++ standardization process,
through the BSI and ISO, as well other language standardization
efforts. Kevlin is also known for his writing, which has included a
POSA volume [POSA4], conference papers, and regular (and irregular)
columns for many publications, including C++ Report, C/C++ Users
Journal, Java Report, JavaSpektrum, Application Development Advisor, The Register, EXE, and Overload.
In what passes for spare time, Kevlin enjoys spending time with Carolyn, his wife, and Stefan and Yannick, their two sons. This time takes
in Lego, toy fixing, reading, and the odd beer or glass of wine.

Douglas C. Schmidt
Doug Schmidt is a Professor of Computer Science and Associate Chair
of the Computer Science and Engineering program at Vanderbilt University, Nashville, Tennessee, USA. His research focuses on patterns
and pattern languages, optimization principles, and empirical analysis of techniques that facilitate the development of quality of service
(QoS)-enabled component middleware and model-driven engineering
tools that support distributed real-time and embedded systems.
Doug is an internationally-recognized expert on patterns, objectoriented frameworks, real-time middleware, modeling tools, and opensource development. He has published over 300 papers in top technical
journals and conferences, has co-authored books on patterns [POSA2]
[POSA4] and C++ network programming [SH02] [SH03], and has also
co-edited several popular books on patterns [PLoPD1] and frameworks [FJS99a] [FJS99b]. In addition to his academic research, Doug
has led the development of ACE, TAO, CIAO, and CoSMIC, which are
widely used open-source middleware frameworks and model-driven
engineering tools that contain a rich set of reusable components implemented using the patterns presented in this book.
In his rare spare time Doug enjoys spending time with his wife Lori
and their son Bronson, as well as weight-lifting, guitar playing, debating world history and politics, and driving Chevy Corvettes.

flast.fm Page xxxi Wednesday, March 21, 2007 11:13 AM

About this Book

Software patterns have significantly changed the way we design, implement, and think about computing systems. Patterns provide us with
a vocabulary to express architectural visions, as well as examples of
representative designs and detailed implementations that are clear
and to the point. Presenting pieces of software in terms of their constituent patterns also allows us to communicate more effectively, with
fewer words and less ambiguity.
Since the mid-1990s many software systems, including major parts
of the Java and C# programming languages and libraries, were developed with the help of patterns. Sometimes these patterns were applied
selectively to address specific challenges and problems. At other times
they were used holistically to support the construction of software
systems from the definition of their baseline architectures to the realization of their fine-grained details. Today the use of patterns has become a valuable commodity for software professionals.
Over the past decade and a half, a large body of literature has been
created to document known patterns in a wide range of areas related
to software development, including organization and process, application and technical domains, and best programming practices. This
literature provides concrete guidance for practicing software engineers and increasingly influences the education of students. Each
year new books and conference proceedings are published with yet
more patterns, increasing the depth and breadth of software development knowledge codified in pattern form.
In the same way, the knowledge of, and experience with, applying patterns has also grown steadily, along with our knowledge about the
pattern concept itself: its inherent properties, different flavors, and
relationships with other technologies. In contrast to the ever-growing
number of documented and refactored concrete patterns, however,
publications about patterns and the pattern concept have been

flast.fm Page xxxii Wednesday, March 21, 2007 11:13 AM

xxxii

About this Book

updated only sparsely and in selected areas since the mid-1990s,
despite the enormous increase of conceptual knowledge in the software patterns community. The introduction to software patterns in A
System of Patterns [POSA1] and Design Patterns [GoF95], and the
white paper on Software Patterns [Cope96], remain the most relevant
sources about the pattern concept. Furthermore, only relatively recently
have publications started to discuss and document pattern sequences
explicitly [CoHa04] [PCW05] [Hen05b].
To summarize the current state of affairs, no complete and up-todate work on the pattern concept is available. Moreover, knowledge
of the latest advances in the conceptual foundations of patterns
remains locked in the heads of a few experts and thought leaders in
the patterns community. Mining this knowledge and documenting it
for consumption by the broader software development community is
the intention of this book, On Patterns and Pattern Languages, which
is the fifth and final volume in the Pattern-Oriented Software Architecture series.
In this book we present, discuss, contrast, and relate the many known
flavors and applications of the pattern concept: stand-alone patterns,
pattern complements, pattern compounds, pattern stories, pattern
sequences, and—last but not least—pattern languages. For each concept flavor we investigate its fundamental and advanced properties,
and explore insights that are well-accepted by the pattern community,
as well as perspectives that are still the subject of discussion and dispute. We also discuss how patterns support and interact with other
technologies commonly used in software development. In a nutshell,
we provide an overview of the current state of knowledge and practice
in software patterns.
Note, however, that while we are general and broad regarding the
elaboration and discussion of the pattern concept itself, the concrete
examples we use to illustrate or motivate different aspects of the concept focus mostly on software design patterns—as opposed to other
types of patterns such as organizational patterns, configurationmanagement patterns, and patterns for specific application domains.
The reason for this (self-)restriction is twofold. First, the majority of
all documented software patterns are software design patterns, so we
have a wealth of material for our examples. Second, the largest group
of software pattern users are architects and developers—thus our

flast.fm Page xxxiii Wednesday, March 21, 2007 11:13 AM

About this Book

xxxiii

focus on software design patterns allows us to explain the ‘theory’
behind patterns using practical examples with which this group is
most familiar.

Intended Audience
The main audience of the book are software professionals interested
in the conceptual foundations of patterns. Our primary goal is to help
such professionals broaden, deepen, and complete their knowledge
and understanding of the pattern concept so that they know what and
how patterns can contribute to their projects. Our other goals are to
help them avoid common misconceptions about patterns, and apply
concrete patterns more effectively in their daily software development
work.
This book is also suitable for undergraduate or graduate students
who have a solid grasp of software engineering, programming languages, runtime environments, and tools. For this audience, the book
can help them to learn more about what patterns are and how they
can help with the design and implementation of high-quality software.

Structure and Content
The book is structured into three main parts, which are surrounded
and supported by several smaller chapters that motivate and complete its vision and content.
Chapter 0, Beyond the Hype, reflects on the original definitions of the
pattern concept and discusses how these definitions are received and
understood by the software community. Our analysis suggests that
some adjustments and enhancements are useful to avoid misconceptions when understanding patterns, and to help prevent the misapplication of patterns in software projects. This introductory chapter
provides the foundation for the three main parts of the book, which
elaborate and discuss these adjustments and enhancements in
greater detail to provide a more complete and consistent picture of
the pattern concept.

flast.fm Page xxxiv Wednesday, March 21, 2007 11:13 AM

xxxiv

About this Book

Part I, Inside Patterns, reflects on the use of stand-alone patterns, and
presents and discusses the insights into patterns we have collectively
gained over the last decade. These insights complement existing pattern definitions, helping us to understand patterns at a deeper level.
Part II, Between Patterns, moves outside individual patterns to explore
the relationships between patterns: sometimes a set of patterns represent alternatives to one another, sometimes they are adjuncts to one
another, and sometimes they are bound together as a tightly-knit
group. Beyond the common, passive notion of a collection, this part of
the book also considers how patterns can be organized as a sequence,
with patterns applied one after another in a narrative flow, thereby
adding an active voice to the use of patterns in the design process.
Part III, Into Pattern Languages, builds on the concepts and conclusions of the first two parts by introducing pattern languages. Compared
with individual patterns and pattern sequences, pattern languages
provide more holistic support for using patterns in the design and implementation of software for specific technical or application domains.
They achieve this goal by enlisting multiple patterns for each problem
that arises in their respective domains, weaving them together to define
a generative and domain-specific software development process.
Chapter 14, From Patterns To People, picks up the discussion about
the concept of patterns from the first three parts of the book, to conclude that despite all technology within patterns and the support they
provide for other software technologies, the prime audience of patterns is people.
Chapter 15, The Past, Presence, and Future of Patterns, revisits our
2004 forecast on where we expected patterns to go that was published
in the third volume of the Pattern-Oriented Software Architecture series.
We discuss the directions that patterns have actually taken during the
past three years and analyze where patterns and the patterns community are now. Based on this retrospection, we revise our vision about
future research and the application of patterns and pattern languages.
This book is the last volume we plan to publish within the POSA series—at least for now. Chapter 16, All Good Things…, therefore wraps
up and concludes our more than fifteen years of work on, and experience with, patterns, and examines the five volumes of the POSA series
that we have written during this time.

flast.fm Page xxxv Wednesday, March 21, 2007 11:13 AM

About this Book

xxxv

The book ends with a summary of all the pattern concepts we discuss,
a chapter with thumbnail descriptions of all the patterns we reference
in the book, an extensive list of references to work in the field, a pattern index, a general subject index, and an index of names that lists
everyone who helped us shape this book.
There are undoubtedly properties and aspects of the pattern concept
that we have omitted, or which will emerge over time with even greater
understanding of patterns and their use in practical software development. If you have comments, constructive criticism, or suggestions for
improving the style and content of this book, please send them to us
via e-mail to siemens-patterns@cs.uiuc.edu. Guidelines for subscription can be found on the patterns home page at http://hillside.net/
patterns/. This link also provides an important source of information
on many aspects of patterns, such as available and forthcoming books,
conferences on patterns, papers on patterns, and so on.

Acknowledgments
It is a pleasure for us to thank the many people who supported us in
creating this book, either by sharing their knowledge with us or by
reviewing earlier drafts of its parts and providing useful feedback.
First and foremost, we want to thank John Vlissides, to whom we also
dedicate this book. John was one of the most brilliant minds in the software patterns community—as ground-breaking thought leader and coauthor of the legendary and seminal Gang-of-Four book [GoF95], and
as ‘discoverer’ and mentor of many now well-known and world-class
pattern experts. The inspirations and foundations from his work have
significantly influenced and helped shape the pattern concept we elaborate and discuss in this book.
Champion review honors go to Wayne Cool, Richard P. Gabriel, Michael
Kircher, James Noble, and Linda Rising, who reviewed all our material
in depth, focusing on its correctness, completeness, consistency, and
quality. Their feedback significantly increased the quality of material
in the book. Wayne Cool also contributed many ideas and thoughts
that we explore in depth in the book.
In addition, we presented parts of the material in the book at four EuroPLoP pattern conferences and also to several pattern experts. Alan
O’Callaghan, Lise Hvatum, Allan Kelly, Doug Lea, Klaus Marquardt,

flast.fm Page xxxvi Wednesday, March 21, 2007 11:13 AM

xxxvi

About this Book

Tim O’Reilly, Michael Stal, Simon St. Laurent, Steve Vinoski, Markus
Völter, Uwe Zdun, and Liping Zhao provided us with extensive feedback,
which led to many minor and also some major revisions of various
aspects of the pattern concept and their presentation.
Many thanks also go to Mai Skou Nielsen, who permitted us to use
photos from her collection in the book.
Special thanks go to Lothar Borrmann and Reinhold Achatz for their
managerial support and backing at the software engineering labs of
Corporate Technology of Siemens AG, Munich, Germany.
Very special thanks go to our editor, Sally Tickner, our former editor
Gaynor Redvers-Mutton, and everyone else at John Wiley & Sons who
made it possible to publish this book. On a sunny evening at EuroPLoP 2002, Gaynor convinced us to write this POSA volume, and
she also accompanied the first two years of its creation. Sally, in turn,
had an enormous amount of patience with us during the two additional and unplanned years we spent completing the manuscript.
Very special thanks also go to Steve Rickaby, of WordMongers Ltd,
our copy editor, for enhancing our written material. Steve accompanied all five volumes of the POSA series with his advice and support.
Last, but not least, we thank our families for their patience and support during the writing of this book!

flast.fm Page xxxvii Wednesday, March 21, 2007 11:13 AM

Guide to the Reader

The White Rabbit put on his spectacles.
“Where shall I begin, please your Majesty?” he asked.
“Begin at the beginning,” the King said, very gravely,
“and go on till you come to the end: then stop.”
Lewis Carroll, Alice’s Adventures in Wonderland

This book is structured and written so that the most convenient way
to read it is from cover to cover. If you know where you want to go,
however, you can choose your own route through the book. In this
case, the following hints can help you decide which topics to focus on
and the order in which to read them.

flast.fm Page xxxviii Wednesday, March 21, 2007 11:13 AM

xxxviii

Guide to the Reader

A Short Story about Patterns
This book provides an in-depth exploration of the pattern concept.
Starting with a popular—yet brief and incomplete—pattern definition,
we first motivate, examine, and develop the inherent properties of
stand-alone patterns. A solid understanding of what a stand-alone
pattern is—and what it is not—helps when applying individual patterns effectively in software development.
We next explore the space ‘between’ patterns. Patterns are fond of
company and can connect to one another through a variety of relationships: they can form alternatives to one another, or natural complements, or define a specific arrangement that is applied wholesale.
Patterns can also line up in specific sequences that, when applied,
generate and inform the architectures of concrete software systems.
Knowing about and understanding the multifaceted relationships
that can exist between patterns supports the effective use of a set of
patterns in software development.
Finally, we enrich the concept of stand-alone patterns with the various
forms of relationships between patterns, to elaborate the notion of pattern languages. Pattern languages weave a set of patterns together to
define a generative software development process for designing software for specific applications or technical domain. Pattern languages
realize the vision and goal of pattern-based software development that
we had in mind when we started the Pattern-Oriented Software Architecture series over ten years ago.
All the concepts we explore and develop build on one another. The
various types of relationships between patterns take advantage of the
properties of stand-alone patterns. Pattern languages further build on
and take advantage of the relationships between patterns. Starting
with an informal and intuitive characterization of what a pattern is,
we progressively mine and elaborate the different properties and facets of the pattern concept, until we have developed a more complete
and consistent picture of what patterns are, what they are not, how
they can support you when developing software, and how they relate
to other software technologies and techniques.

flast.fm Page xxxix Wednesday, March 21, 2007 11:13 AM

Guide to the Reader

xxxix

Patterns Viewed from Specific Angles
If you prefer to take a different route through the book—for example
to focus on a specific perspective on the pattern concept—we suggest
you read the respective parts and chapters in an order that is most
interesting or relevant for you. Note, however, that each part of the
book, and each chapter within a part, builds on the concepts investigated and developed in the preceding chapters and parts. If you are
unfamiliar with a specific aspect referenced in the chapters you are
reading, the Pattern Concept Summary at the end of the book provides
a condensed description of all aspects of the pattern concepts we
explore in this book. If you are unfamiliar with any pattern we mention, Referenced Patterns at the end of the book cites the sources for
each pattern referenced and includes a brief description of it.

All About Patterns from One Source
Since we follow a grass roots approach to investigating the pattern
concept, you can read and comprehend the book even if this is your
initial exposure to patterns. We also build on and integrate the earlier
works on the pattern concept published in the mid to late 1990s: the
fundamental concepts and terminology related to patterns for software architectures and designs outlined in A System of Patterns
[POSA1] and Design Patterns [GoF95], and the elaboration of the pattern language concept in Jim Coplien’s white paper on Software Patterns [Cope96]. If you are familiar with these works you will find what
you already know about patterns being reinforced, extended, and—we
hope—fulfilled in this book.

flast.fm Page xl Wednesday, March 21, 2007 11:13 AM

c00.fm Page 1 Saturday, March 17, 2007 1:58 PM

0

Beyond the Hype

Use missteps as stepping stones to deeper
understanding and greater achievement.
Susan L. Taylor, journalist

This chapter revisits our pattern definition from 1996, which was presented in A System Of Patterns, the first volume of the Pattern-Oriented
Software Architecture series, and subjects it to a careful and thorough
examination. Our analysis suggests that some adjustments and enhancements are useful, even necessary, to avoid misconceptions in
understanding patterns, and therefore to help prevent the misapplication and misappropriation of patterns in software projects.

c00.fm Page 2 Saturday, March 17, 2007 1:58 PM

2

0.1

Beyond the Hype

Beginnings…
A key event in the emergence and adoption of patterns within software
was the ‘birds of a feather’ session run by Bruce Anderson at ECOOP
in 1990. It was entitled Towards an Architecture Handbook, and led to
workshops at the next three OOPSLA conferences, where the Gangof-Four (GoF) first met [GoF95]:
Our first collective experience in the study of software architecture
was at the OOPSLA ’91 workshop led by Bruce Anderson. The
workshop was dedicated to developing a handbook for software architects. (Judging from this book, we suspect ‘architecture encyclopedia’ will be a more appropriate name than ‘architecture
handbook.’)

These OOPSLA workshops were also where some of the earliest PatternOriented Software Architecture work was presented. The assembly of
a handbook or encyclopedia of software architecture is an ambitious
project, and one that has inspired many within the patterns community to dig deeply into their experience. Most notably, Grady Booch
has done field studies to survey software systems actively in search of
sound patterns of practice [Booch].
Enthusiasm for patterns has increased since the release of the seminal work by the Gang-of-Four [GoF95]. Its successors, which include
collections of selected patterns from the Pattern Languages of Programming (PLoP) conferences [PLoPD1] [PLoPD2] [PLoPD3] [PLoPD4]
[PLoPD5] and the first four volumes from the Pattern-Oriented Software Architecture series [POSA1] [POSA2] [POSA3] [POSA4], further
kindled the interest in patterns sparked by the Gang-of-Four book
and earlier work on software idioms [Cope92] and user-interface patterns [BeCu87].
Ever since the publication of the GoF book in 1994, software developers around the world have embraced this ‘new idea,’ with the hope
that patterns would help them untangle tricky problems into well-knit
solutions—something with elegance, directness, and versatility. The
pattern concept and many specific patterns found their way into the
vocabulary and code of many software development projects, books,
and university courses. A movement had begun. It was, and still is,
thriving.

c00.fm Page 3 Saturday, March 17, 2007 1:58 PM

A Story of Success… with Some Exceptions

0.2

3

A Story of Success… with Some Exceptions
One reason for the success of patterns is that they constitute a grass
roots initiative to build on and draw from the collective experience of
skilled software designers. Although each development project is new
and distinct in its own way, such projects rarely tackle genuinely new
problems that demand truly novel solutions. Developers may sometimes arrive at similar solutions independently, or they often recall a
similar problem they once solved successfully in a different situation,
reusing its essence and adapting its details to resolve a new problem.
Expert architects and developers can draw on a large body of these
‘solution schemes’ to address design problems that arise when developing new systems and maintaining existing ones.
Distilling commonality from this pairing of application-specific design
problems and their solutions leads comfortably to a central theme of
the pattern concept: each pattern captures a solution and its relationship to the corresponding problem, framing it in a more readily accessible form. Patterns can teach novices many of the concepts they need
to work on projects of modest complexity, helping them to act with
greater confidence in selecting appropriate designs and employing
suitable practices. Patterns can similarly support experts in the development of more complex software systems, offering them alternative perspectives on familiar problems and enabling them to learn
from the experience of other experts. Few other concepts in the world
of software development have similar or comparable properties.
Consequently there are many pattern success stories to tell: stories
about systems whose architectures and development benefited from
being designed and refined consciously and carefully with patterns,
including tales from telecommunications [Ris98], business information systems [KC97], industrial automation [BGHS98], warehouse
management [Bus03a], network management [KTB98] [Sch98], network protocols [HJE95], communication middleware [SC99], and
other industrial-strength systems [BCC+96].
Naturally, the role of patterns, and their successes, extends beyond
the realm of software design. Patterns have been mined, championed, and applied explicitly in many other domains, including patterns for introducing change into organizations [MaRi04], patterns

c00.fm Page 4 Saturday, March 17, 2007 1:58 PM

4

Beyond the Hype

for organizational structure [CoHa04], patterns for development
practices [Cun96], patterns for teaching [PPP], patterns for configuration management [BeAp02], patterns for security [SFHBS06], patterns
for documentation [Rüp03], and even patterns for writing patterns
[MD97]! Many diverse examples of patterns and their application
have captured and related successful strategies effectively in a domain for others to use.

Under Observation
Alas, success is neither universal nor unconditional. There are also
many tales of failure to relate: stories about systems in which patterns were used intentionally and explicitly in design, but whose
architectures were penalized by unnecessary and accidental complexity. Consider the following case:
In a development project a problem arose where some components
were dependent on the information provided by another component. Whenever information maintained by the information provider was modified, it was necessary to restore data consistency with
the information consumers. The team knew about the OBSERVER
pattern, and it seemed like the ‘right’ solution to the problem—with
the information provider as a subject and the information consumers as observers. The team therefore applied the OBSERVER pattern
to resolve the problem.
One information consumer implemented as an observer also served
as an information provider for another set of components. The
OBSERVER pattern, therefore, could be applied a second time. This,
however, raised a ‘problem.’ The pattern’s description in the Gangof-Four book [GoF95] does not specify a class that is both a subject and an observer. How could such a component then be built
without ‘violating’ the pattern?
The project’s solution was to introduce three classes for this component. The first class implemented the component’s observer
functionality and the second class its subject part. The third class
was derived from both these classes via multiple inheritance and
provided functionality for coordinating state and computation of
its two superclasses.

c00.fm Page 5 Saturday, March 17, 2007 1:58 PM

A Story of Success… with Some Exceptions

5

In other words, in both cases where OBSERVER was applicable, the
project team faithfully transliterated the OBSERVER class diagram
pictured in the Gang-of-Four book and connected the two island
implementations with an additional glue component. A single coherent responsibility had been scattered across three different
classes, diluting the cohesion of the design, with downstream development and developers paying the price in decreased comprehension and increased complexity.

Observer
Implementation

void update ()
begin
# React on notification
# and update own state.
...
end

Subject
Implementation

Glue
Implementation

void notify (Event e)
begin
# Notify all registered
# subscribers interested
# in the event about its
# occurrence.
...
end

void update ()
begin
# Update state based on ObserverImplementation superclass.
ObserverImplementation.update ();
# Notify based on SubjectImplementation superclass.
SubjectImplementation.notify (ObserverStateChange);
end

A much better solution—and one that the project came up with as a
result of design mentoring—is to implement a single class that includes all three roles. This ‘integrated’ design is much easier to explain and maintain than the ‘three class’ structure. Moreover, it is still
a faithful realization of the OBSERVER pattern, even though it is not an
exact reproduction the class diagram in the Gang-of-Four’s OBSERVER
description [GoF95].

c00.fm Page 6 Saturday, March 17, 2007 1:58 PM

6

Beyond the Hype

In a State
But of course, the OBSERVER tale is not an isolated case:
Another development team, recently introduced to UML and
Gang-of-Four patterns, found that a number of classes in their
system described objects with modal, event-driven behavior. Having initially struggled to represent this vital aspect through sequence diagrams, they recalled the use of statecharts, which
greatly simplified the description and communication of the object
lifecycles.
The next challenge was to reify such state models in code. Turning
to the Gang-of-Four, they came across the STATE pattern. This pattern is the only one in the Gang-of-Four catalog that directly addresses the realization of such stateful behavior, and has a name
to match. It is also quite a sophisticated pattern, introducing
many new classes into a system and significantly decentralizing
the behavior of objects. Following a big up-front design approach,
the team chose to implement each object lifecycle they had modeled as a statechart—which ran to quite a few—in terms of the
STATE pattern. The result was a class explosion and an increase in
the design complexity, with a corresponding decrease in comprehensibility and maintainability.
The indiscriminate use of the STATE pattern arose in part from a
misinterpretation of its name—that it was the state pattern rather
than a state pattern—and in part from a desire to pigeonhole all
design problems of a particular type with a single solution, namely
that all statecharts should be implemented the same way.

A more careful reading of the STATE pattern description reveals that it
is better served by its ‘also known as’ name of OBJECTS FOR STATES—
a name that both accurately describes its structure and accommodates the idea of alternative solutions. More profoundly, however,
comes the understanding that many design problems are superficially
related—for example, the common use of state machines as an abstraction to describe object lifecycles neither requires nor implies a
common design approach for all classes so modeled.
No matter how attractive the idea of a one-size-fits-all solution might
be, such a supposedly simplifying assumption is simplistic rather than
simple. In this case it led to an overall increase in complexity, because
a heavyweight pattern was used beyond its scope of applicability.

c00.fm Page 7 Saturday, March 17, 2007 1:58 PM

A Story of Success… with Some Exceptions

7

Sometimes lookup tables or collections of objects are the appropriate
solution for managing object lifecycles. At other times the solution
can be even simpler, by introducing an extra flag variable or query
method. In a few cases, however, the power of the OBJECTS FOR
STATES pattern is both appropriate and simplifying.

Beyond Prescription
Part of what makes design design is the recognition of alternative
competing solutions. Patterns can help make these solutions explicit
along with the criteria for their selection—their forces and their consequences. It is perhaps revealing that one member of the team in the
STATE story above expressed disappointment on discovering that
there were more than twenty-three patterns available for software development! The hope that the Gang-of-Four had created a potted,
packaged, and predigested cure-all was frustrated.
The question remains as to why these and other such episodes take
place. Why did so many projects fail to use patterns successfully?
Worse yet, why do many projects continue to fail to use patterns successfully despite the wealth of literature and experience gained during
the past decade? All these projects hoped, after all, to benefit from using patterns. A cynical response would be to point the finger of blame
at the whole pattern concept: are patterns really an effective way to
capture and communicate design knowledge of any sort? By exploring
pattern concepts and examples in detail in this book, we hope to reaffirm that patterns are one of the more effective means for naming,
organizing, and reasoning about design knowledge.
A less cynical, but nonetheless pessimistic, response would be to observe that nothing can ever be perfect, therefore mistakes are an inevitable part of any human undertaking. There is a more constructive
perspective, however, that both accepts human imperfection and recognizes there is always room for improvement in practice. It appears
that many projects that fail to use patterns effectively claim to follow
popular pattern definitions explicitly and to the letter, applying the
selected patterns as specified in their descriptions. Perhaps there is
something missing from or overlooked in the existing definitions of
the software pattern concept, or even in the patterns themselves and
their content?

c00.fm Page 8 Saturday, March 17, 2007 1:58 PM

8

0.3

Beyond the Hype

Pattern Definitions and their Interpretations
To seek answers to the previous questions, and to help developers
gain a sufficiently complete, realistic, and accurate picture of patterns, it is worth examining some of the more popular pattern definitions, as well as their mainstream interpretations by the software
community.
Many recent books on software development include a definition of
patterns for software and, if it is not the authors’ own, they explicitly
discuss or reference a definition coined by someone else. In these
books, the common objective of the authors is to introduce the concept of patterns, capturing it as precisely and relevantly as possible
for the needs and scope of their work. The following is the definition
from A System of Patterns [POSA1], the first volume of the PatternOriented Software Architecture series:
A pattern for software architecture describes a particular recurring
design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution
scheme is specified by describing its constituent components,
their responsibilities and relationships, and the ways in which
they collaborate.

Along with this definition, [POSA1] and [Sch95] discuss several
properties of patterns for software architecture that we revisit below:
• Patterns document existing best practices built on tried and tested
design experience. Patterns are not invented or created artificially
just to be patterns. Rather they ‘distill and provide a means to reuse the design knowledge gained by experienced practitioners,’ so
that developers familiar with an adequate set of patterns ‘can apply
them immediately to design problems without having to rediscover
them’ [GoF95]. If the patterns are implemented appropriately, developers can rely on their effectiveness.
Experience and best practice have traditionally lived in the heads
of skilled developers, or they have been encoded, buried deep and
reflected within complex system source code. Explicit highlighting
of key design strategies and tactics through patterns can help novice developers and new participants ascend the learning curve on a

c00.fm Page 9 Saturday, March 17, 2007 1:58 PM

Pattern Definitions and their Interpretations

9

project. It also lets skilled developers share their knowledge more
effectively, giving all parties good role models on which to base their
work.
• Patterns identify and specify abstractions that are above the level of
single objects, classes, and components. A particular application
component can rarely address a complex problem alone—at least
not very effectively or with any semblance of cohesion. The solution
parts of most patterns therefore introduce several roles that multiple application components—deployable components, classes, or
objects—can take. In addition, these solution parts specify the relationships and collaborations among the roles they introduce. For
example, the OBSERVER pattern introduces two main roles, subject
and observer, that cooperate via a push-based change-propagation
mechanism to ensure that components can keep their state consistent with one another.
• Patterns provide a common vocabulary and shared understanding
for design concepts. This vocabulary eases the reuse of architectural knowledge and artifacts, even when reuse of particular algorithms, implementations, interfaces, or detailed designs is not
practical or possible. For example, once developers understand the
OBSERVER pattern, there is less need for them to have lengthy discussions on how to keep two cooperating components consistent in
their system. Instead the dialog can be condensed to something
like: ‘Well, I introduced OBSERVER here with this object playing the
role of the subject and those objects being its observers. Events
are sent by callback to observers that registered their interest for
these events with the subject, while information about the state of
the subject is pulled by the observers from the subject.’

c00.fm Page 10 Saturday, March 17, 2007 1:58 PM

10

Beyond the Hype

Developers familiar with OBSERVER can readily understand the design in question and draw a sketch similar to the following.

Observer

Subject

*
void register (Observer subscriber, EventSet events)
begin
# Register the observer‘s callback
# for the event of interest.
subscribers.add (subscriber, events);
end
void notify (Event event)
begin
# For all observers registered for the event
# notify them via callback.
for each subscriber in subscribers[event.type]
subscriber.callback (event);
end
void callback (Event event)
begin
# Pull information from the subject
# and update own state.
data = subject.getData ();
myState = ...;
end

:Subject

:Observer
register (this, events)

notify (event)

callback (event)
getData ()

c00.fm Page 11 Saturday, March 17, 2007 1:58 PM

Pattern Definitions and their Interpretations

11

As a result, patterns can help to redirect the unproductive preoccupation with programming language and API zealotry that can
often plague a software project. In particular, patterns enable developers from different programming language cultures to share
design insights of mutual interest without being distracted by ‘language wars.’ By way of balance, patterns not only enable communication amongst members from different communities, they also
help to refocus the concerns of a particular language community
through a recognized body of idiomatic practice. The idioms of C++
are not always useful, benign, or even possible when applied in Java, and vice versa, but they serve to capture knowledge relevant
and essential to that community.
Patterns can also help the dialog and transfer of knowledge between different generations of developers and the technologies with
which they are most familiar. The code may look different, and the
‘acronym soup’ may have a different mix, but often there are patterns in common that underpin the old and the new. For example,
many patterns that had their origins in the distributed object computing domain, documented, for example, in Patterns for Concurrent and Networked Objects [POSA2] and Server Component Patterns
[VSW02], are still applicable in approaches that have since become
popular, such as service-oriented architectures (SOA) [Kaye03]
and component models [VSW02]. This transfer of knowledge also occurs with application concepts, not just underlying technology, as
evidenced in approaches such as domain-driven design [Evans03].
• Patterns are a means of documenting software architectures. With
their explicit evaluation of consequences and implementation
trade-offs, patterns can be used to track the reasons why specific
design choices were selected and others rejected. The practice and
path of software development and maintenance can be smoothed
and demystified by documenting the intent, structure, and behavior of a piece of software in terms of the patterns found within it
[Prec97] [PUS97]. This use of patterns is especially beneficial for
product-line architectures [Bosch00] [Coc97]. Developers will struggle to use a product-line architecture correctly and effectively without an understanding of its fundamental structure, control flow, and
the mechanisms available for tailoring it toward a specific application, but at the same time they should not be swamped by its

c00.fm Page 12 Saturday, March 17, 2007 1:58 PM

12

Beyond the Hype

implementation details. Similar arguments hold when building an
application on top of any software infrastructure, such as communication middleware or GUI frameworks. Pattern-based documentation of an architecture can help to resolve this conflict by allowing
developers to focus on key design decisions and their supporting
rationale, but avoids getting mired in detail that—although interesting and essential to its creator—does not necessarily help other
developers to work with it.
• Patterns support the construction of software with well-defined properties. Some patterns define a skeleton of behavior that goes some
of the way toward meeting the functional requirements for applications in a particular domain. For example, patterns have been documented for structuring corporate finance and accounting systems
[Fow97], telecommunication systems [Ris98], and for improving the
capacity of reactive systems [Mes96]. Patterns that have a more
architectural focus explicitly address the operational and developmental requirements of software systems, such as resource management [POSA3], security [SFHBS06], performance and scalability
[POSA2], and extensibility [GoF95].
• Patterns capture experience in a form that can be independent of
specific project details and constraints, implementation paradigm,
and often even programming language. By abstracting from aspects that can distract from understanding the potential traps
and pitfalls in a domain, patterns support developers in the selection of suitable software architectures, designs, and coding principles to address new design challenges in new projects, without
wasting time and effort implementing solutions that are known to
be inefficient, error-prone, unmaintainable, or simply broken. For
example, the patterns documented in the POSA series [POSA1]
[POSA2] [POSA3] [POSA4] are described so they can be used to
construct almost all types of system: object-oriented or procedural,
distributed and concurrent or collocated and sequential, component-based or monolithic, built on top of off-the-shelf middleware
or fully hand-crafted.
Other well-known definitions of patterns for software are quite similar to our definition in A System of Patterns. For example, the definition given by the Gang-of-Four [GoF95] and those collected from
various sources by Brad Appleton [App96] also discuss similar pattern

c00.fm Page 13 Saturday, March 17, 2007 1:58 PM

Pattern Definitions and their Interpretations

13

properties. These references capture where we and many others
from the pattern community were at the end of the last millennium.
These ‘early’ definitions served well for introducing patterns to a wide
audience, and are still useful today. Developers who participated in
projects that applied patterns successfully will probably agree with
them and confirm that patterns have the properties we discussed
above. Yet these definitions do not seem quite deep enough to ensure
a truly shared understanding of patterns. Without wishing to appear
overly prescriptive or too formal, there is still too much latitude for
misinterpretation and, therefore, misapplication of patterns. In particular, we have observed the following traps and pitfalls repeatedly:
• Developers may be tempted to recast all their software development
activities and artifacts as patterns. For example, they may document
existing algorithms or data structures such as binary searches or
linked lists in pattern form. Or, as another example, the so-called
‘Java pattern’ from CORBA Design Patterns [MM97] attempts to
recast a discussion of some properties and benefits of the Java
platform as a pattern, with the implication that Java is the only solution that can be identified with these properties and benefits. Although this exercise may be intellectually satisfying to the authors,
it can be counter-productive if it does not markedly improve key
developmental qualities of software development such as communication or comprehensibility, or some operational quality of the
software such as efficiency or extensibility.
• Patterns are not just pieces of neat design. Developers may be tempted
to brand each novel and intricate design—and even each systemspecific design decision—as a new pattern of their own invention.
Using a pattern form to document these designs is certainly helpful.
For example, some of the proposed patterns in CORBA Design Patterns [MM97] address general distributed computing techniques,
such as the CORBA-CGI GATEWAY, but their definition is very tightly
connected to the CORBA context and specification. Other proposed
solutions in CORBA Design Patterns describe designs that are recurrent but have been shown to be impractical, such as the solution
described in the DISTRIBUTED CALLBACK pattern.
Calling such design documentations ‘patterns,’ however, can give
the impression that an application’s architecture is based on
sound and proven design knowledge, even when it is not. This

c00.fm Page 14 Saturday, March 17, 2007 1:58 PM

14

Beyond the Hype

impression may in turn prevent other developers from questioning the design and implementation decisions made, or from exploring alternatives—patterns are often considered a synonym for quality design, so the design must therefore be good if it is pattern
based, right? Blind trust in any design, whether based explicitly on
patterns or not, is unlikely to ensure that software has the desired
qualities. Solutions therefore require recurrence and generality to
attain the pattern ‘brand,’ and good patterns are those solutions
that are both recurrent and proven.
• Developers tend to see patterns as fixed affairs—islands, blueprints,
or very specific configurations of classes. Although a formal diagram
and sample code are often part of a software pattern’s description,
they are not the pattern. As demonstrated by the OBSERVER story
at the beginning of this chapter, however, the view that the diagram
is the pattern prevails. This limited view has held many developers
back from a more reasoned and practical understanding of patterns: adaptation to the specific needs of an application is part of a
pattern’s natural remit. A pattern should be seen as a ‘dance of
interacting parts, pegged down by various sorts of limits’ [Bat79].
Unfortunately, this fluid image is not often conveyed by existing
pattern definitions.
• Patterns are not coding guidelines. Coding guidelines may be put
together—in part—from patterns focused on code style, but the
converse is not as faithful a process. Although many coding guidelines are idiomatic, this does not automatically qualify them as patterns. For example, Sun Microsystem’s JavaBeans specification
[Sun97] claimed the consistent use of get and set prefixes for property accessors as ‘design patterns.’ While these prefixes are ‘patterns’ in the sense of ‘regular-expression pattern matching,’ they do
not solve profound design issues in general design or specifically
within Java code. There may be pattern here, but it is not the use
of get and set: it is the use of a consistent naming scheme to establish a protocol in support of a DYNAMIC INVOCATION INTERFACE. The
chosen protocol was based on get and set prefixes, but could just
as easily—although perhaps not as intuitively or popularly—have
been foo and bar suffixes.

c00.fm Page 15 Saturday, March 17, 2007 1:58 PM

Pattern Definitions and their Interpretations

15

• A limited or misunderstood pattern vocabulary may cause developers
to apply the wrong pattern in response to a given problem. Knowing
when a pattern is appropriate for a particular situation requires
good judgement: misapplication can yield inappropriate designs
and implementations. Similarly, superficial knowledge of a pattern
may give developers the impression that they know more about the
solution to a problem than they actually do. For example, simply
knowing the structure and participants introduced by relatively
complex patterns such as PROACTOR and REFLECTION is only a single
aspect of effective pattern application. The devil is always in the details, however, and a pattern’s essence is reflected in its context
and its forces, not just in its structure. The successful realization
of a pattern is thus reliant on—and not a replacement for—solid
design and implementation skills.
• Developers may believe that patterns help them to formulate intricate
architectures by following a recipe or through mechanical application. Conscious integration of patterns into software development
processes is a human-intensive activity. As with other useful software techniques and tools, the successful application of patterns
requires teams with a mix of developers who can draw on both concrete experience in a domain and the ability to generalize from myriad implementation details to capture the essential properties of
software architectures and components via patterns. Despite the
broader geographic net cast by today’s ‘flat world’ of information
technology [Fri06], surprisingly few developers today possess both
these skills with comparable proficiency.
• There are software systems whose development can succeed only if
its developers explore new ideas. This need for novelty and exploration is particularly important for systems that ‘enter’ a new domain
that lacks software-based experience. Examples include the first
e-commerce applications ever developed and the early software
systems for industrial automation. Thinking solely in terms of proven
patterns—which, by definition, capture solutions that worked well
in the past—might not offer the right toolbox for the new design
challenges raised by leading-edge and ground-breaking systems. A
narrow, patterns-only focus could therefore actually hinder the
success of such projects. Of course, patterns can come into play,
but it is likely that they will focus on the support infrastructure,

c00.fm Page 16 Saturday, March 17, 2007 1:58 PM

16

Beyond the Hype

such as patterns for configuration management usage and communication middleware, and on the development process, such as the
adoption of an agile process tailored for an R&D lifecycle, rather
than patterns for detailed domain-specific design and overall system architecture.
• Expectations must be managed carefully to prevent patterns from
becoming yet another buzzword of ill repute. Developers and managers often have misconceptions about precisely how and what
patterns can contribute to software projects. For example, the use
of patterns does not on its own guarantee correct, extensible, and
efficient software. Organizations with tight delivery schedules, or
those that view software development as a rote uncreative process,
often devote inadequate time and developer resources to cultivate
the design of their systems or a culture of design. In return, they
receive correspondingly limited results when applying patterns,
which are—in contrast to their own practice—expressions of thoughtful design applied creatively in the appropriate context.
• The use of patterns cannot be fully tool-based or automated. Although patterns can contribute significantly to the successful use
of generative software technologies, in particular Aspect-Oriented
Software Development [KLM+97] and Model-Driven Software Development [Sch06a] [SVC06], their use cannot be fully mechanized
[Vö05b]—a hope that both managers and developers often have
when talking about patterns and their use in software construction. Both parties often forget that it is humans who are the prime
consumers of patterns. By intent, patterns are sketches rather
than blueprints. An important part of using a pattern is understanding the problem that it solves, how it solves the problem, and
what the trade-offs of the solution are. Only after a problem is understood and a suitable pattern for its solution carefully selected,
can a specific implementation of this solution be automated or embodied directly into tools and languages. Put another way: understanding is the bottleneck in software development, not typing
source code into a text editor. Automation has an important role to
play in development, but not quite in the way that a simplistic automation of patterns would suggest.

c00.fm Page 17 Saturday, March 17, 2007 1:58 PM

Pattern Definitions and their Interpretations

17

The idea that tools can help to recognize patterns in code or models consistently and automatically is also naïve [PK98] [ACGN01]
[Pet05]. Some patterns, such as COMPOSITE, certainly have a characteristic look to them, a distinctive signature. Most patterns,
however, are more anonymous when stripped of their intent and
dynamics: STRATEGY and OBJECTS FOR STATES, for example, share
the same class diagram, while in some designs STRATEGY can also
be understood as a special case of BRIDGE.
• Patterns are not components: they are not usable out-of-the-box,
commodity items that can just placed into a system in a preplanned
way. Because many software patterns offer a diagram of code components in various roles, there is a temptation to view them as
schemas or templates—just fill out the blanks and you are ready to
run! The original UML specification is quite clear on its plug-andplay view of patterns [RJB99]:
A parameterized collaboration that represents a set of parameterized classifiers, relationships, and behavior that can be applied to
multiple situations by binding elements from the model (usually
classes) to the roles of the pattern. It is a collaboration template.

Although this definition provides patterns with some level of citizenship in the world of UML, it comes at the expense of their freedom.
Only by excluding the most essential features of a pattern—the nature of the problem, the rationale for the solution, the consequences
of applying the solution—can the pattern concept be shoehorned so
tidily into the world of modular parts. In software, parameterization
is a useful tool, and it can at times be a convenient metaphor for
describing the variability and genericity of patterns. However, metaphor is not identity—‘at times’ is not ‘always’ and genericity does
not necessarily imply parameterization, since there are other patterns for achieving genericity.
The UML 2 specification moderates the precise (but inaccurate)
pattern definition of UML 1 with a broader view that acknowledges
a difference in ambition and scope between patterns in the world of
UML and software patterns in general:
A template collaboration that describes the structure of a design
pattern. UML patterns are more limited than those used by the design pattern community. In general, design patterns involve many
non-structural aspects, such as heuristics for their use and usage
trade-offs.

c00.fm Page 18 Saturday, March 17, 2007 1:58 PM

18

Beyond the Hype

This definition is a step in the right direction, but it is clear that
popular methodologies still have a long way to go to reflect a deep
understanding of the pattern concept.
• Pattern-based design is not at odds with—or replaced by—refactoring. There is a temptation to assume that all identifiable patterns
in code must have been applied consciously, that is, put there fully
in the knowledge of what pattern was being used and why. Their
recurring nature suggests otherwise. Good architects call upon
their expertise to produce reasoned designs that are new, yet mature. They will employ patterns, regardless of whether their design
thinking is based on subconscious habits or on explicitly documented reasoning.
Refactoring is to software what gardening is to a garden: a continuous process of addition, removal, rearrangement, and reflection.
Does a good set of refactorings [FBBOR99] eliminate the need for a
pattern vocabulary? After all, refactoring provides a vocabulary for
design and a process by which design can be improved, almost unconsciously. What use are patterns if they are not applied directly?
Are they simply an expression of big up-front design?
To assume that a developer must make an ‘either/or’ decision between patterns or refactoring is to misunderstand the nature of
both patterns and refactoring. Many patterns describe a desired
transformation—from problem to solution—but the associated
mechanics for performing this transformation are either implied or
applicable only when developing new software, while refactorings
provide this vehicle for pre-existing code. Sometimes this relationship is quite explicit. For example, the NULL OBJECT pattern describes the ‘why’ of the idea and the ‘how’ for green-field design,
and the Introduce Null Object refactoring [FBBOR99] describes the
‘how’ for cultivating brown-field code. The transformation process
of a refactoring is often quite specific, mechanical, and code-focused,
which allows the automation of many simpler refactorings in modern development environments.
Refactoring describes transformations but does not always describe the resulting structure or its intent. The names of refactorings are always verb phrases, capturing an imperative, whereas
pattern names are more often noun phrases, describing a structural solution. For example, although Introduce Null Object clearly

c00.fm Page 19 Saturday, March 17, 2007 1:58 PM

Toward a Deeper Understanding of Patterns

19

contains the resulting design structure in its name, most refactorings tend to be named in terms of programming language features:
Extract Method, Extract Class, and Extract Interface result in a
method, a class, and an interface respectively, but the notion of an
intentional structure is missing. There are many reasons a method,
class, or interface may exist, but these structures are not selfdescribing. The NULL OBJECT pattern, in contrast, describes roles
and intention.
When viewed after the fact, a well-factored design is typically patternrich. Without recounting the whole story of the system—‘And then
we had this big class that we split up. And then…’—how else are
developers able to talk about the system in richer terms than just its
classes and methods? Patterns and refactoring are complementary
rather than conflicting [Ker04].
Other software researchers and practitioners report similar misconceptions about the understanding and use of patterns [Vlis98b], and
you can probably extend this list with your own observations. The
very fact that there are so many misconceptions, misinterpretations,
and mistakes, however, suggests that something is often amiss in the
popular perception and definitions of the pattern concept. Such misunderstandings