Praise for Design Patterns Explained, Second Edition:

The explanation of fundamental object-oriented concepts throughout is ex-

ceptional. I have struggled to teach similar concepts to beginners in my
classes and I definitely plan to borrow some of the authors' approaches
(and recommend the book, of course)!

—CLIF NOCK

Well-written, thought-provoking, and very enlightening. A must-read for

anyone interested in design patterns and object-oriented development.

—JAMES HUDDLESTON
This page intentionally left blank
Design Patterns
Explained
The Software Patterns Series
Series Editor: John M. Vlissides

The Software Patterns Series (SPS) comprises pattern literature of lasting significance to
software developers. Software patterns document general solutions to recurring problems
in all software-related spheres, from the technology itself, to the organizations that develop
and distribute it, to the people who use it. Books in the series distill experience from one
or more of these areas into a form that software professionals can apply immediately.

Relevance and impact are the tenets of the SPS. Relevance means each book presents patterns
that solve real problems. Patterns worthy of the name are intrinsically relevant; they are
borne of practitioners’ experiences, not theory or speculation. Patterns have impact when
they change how people work for the better. A book becomes a part of the series not just
because it embraces these tenets, but because it has demonstrated it fulfills them for its
audience.

Titles in the series:

Data Access Patterns: Database Interactions in Object-Oriented Applications; Clifton Nock

Design Patterns Explained, Second Edition: A New Perspective on Object-Oriented Design; Alan Shalloway
and James Trott

Design Patterns in C#; Steven John Metsker

Design Patterns in Java™; Steven John Metsker and William C. Wake

Design Patterns Java™ Workbook; Steven John Metsker

.NET Patterns: Architecture, Design, and Process; Christian Thilmany

Pattern Hatching: Design Patterns Applied; John M. Vlissides

Pattern Languages of Program Design; James O. Coplien and Douglas C. Schmidt

Pattern Languages of Program Design 2; John M. Vlissides, James O. Coplien, and Norman L. Kerth

Pattern Languages of Program Design 3; Robert C. Martin, Dirk Riehle, and Frank Buschmann

Pattern Languages of Program Design 5; Dragos Manolescu, Markus Voelter, and James Noble

Patterns for Parallel Programming; Timothy G. Mattson, Beverly A. Sanders, and Berna L. Massingill

Software Configuration Management Patterns: Effective Teamwork, Practical Integration; Stephen P. Berczuk
and Brad Appleton

The Design Patterns Smalltalk Companion; Sherman Alpert, Kyle Brown, and Bobby Woolf

Use Cases: Patterns and Blueprints; Gunnar Övergaard and Karin Palmkvist

For more information, check out the series web site at www.awprofessional.com/series/swpatterns
Design Patterns
Explained
A New Perspective on Object-Oriented Design
Second Edition

Alan Shalloway
James R. Trott

Boston • San Francisco • New York • Toronto • Montreal

London • Munich • Paris • Madrid
Cape Town • Sydney • Tokyo • Singapore • Mexico City
The authors and publisher have taken care in the preparation of this book, but make no expressed or im-
plied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for
incidental or consequential damages in connection with or arising out of the use of the information or pro-
grams contained herein.
Publisher: John Wait
Acquisitions Editor: John Neidhart
Executive Editor: Stephane Nakib
Editorial Assistant: Ebony Haight
Marketing Manager: Curt Johnson
Publicity: Joan Murray
Managing Editor: Gina Kanouse
Senior Project Editor: Sarah Kearns
Production Editor: Kerry Reardon
Manufacturing Buyer: Dan Uhrig
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trade-
mark claim, the designations have been printed with initial capital letters or in all capitals.
The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales.
For more information, please contact:
U.S. Corporate and Government Sales
(800) 382-3419
corpsales@pearsoned.com
For sales outside of the U.S., please contact:
International Sales
international@pearsoned.com
Visit Addison-Wesley on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data

LOC 2004108740

Copyright © 2005 by Pearson Education, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or trans-
mitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior consent of the publisher. Printed in the United States of America. Published simultane-
ously in Canada.
For information on obtaining permission for use of material from this work, please submit a written re-
quest to:
Pearson Education, Inc
Rights and Contracts Department
501 Boylston Street, Suite 900
Boston, MA 02116
Fax (617) 671 3447

ISBN-10: 0-321-24714-0
ISBN-13: 978-0-321-24714-8
Text printed on recycled paper
1 2 3 4 5 6 7 8 9 10—MA—0605040302
Sixth printing, October 2007
To Leigh, Bryan, Lisa, Michael, and Steven
for their love, support,
encouragement, and sacrifice.

—Alan Shalloway

To Jill, Erika, Lorien, Mikaela, and Geneva,

the roses in the garden of my life.
sola gloria Dei

—James R. Trott
This page intentionally left blank
 Contents

Preface ______________________________________________xix
From Object Orientation to Patterns to True Object
Orientation ___________________________________________xxi
From Artificial Intelligence to Patterns to True Object
Orientation_________________________________________xxviii
A Note About Conventions Used in This Book _______________xxx
Feedback ______________________________________________xxxiv
New in the Second Edition_______________________________xxxiv
Acknowledgments_______________________________________xxxv

PART I
An Introduction to Object-Oriented Software
Development __________________________________________1

Chapter 1
The Object-Oriented Paradigm _____________________3
Overview _________________________________________________3
Before the Object-Oriented Paradigm: Functional Decomposition 4
The Problem of Requirements ________________________________6
Dealing with Changes: Using Functional Decomposition _________8
Dealing with Changing Requirements ________________________11
The Object-Oriented Paradigm ______________________________15
Object-Oriented Programming in Action______________________23
Special Object Methods ____________________________________27
Summary_________________________________________________28
Review Questions _________________________________________30

ix
x Contents

Chapter 2
The UML—The Unified Modeling Language______33
Overview_________________________________________________33
What Is the UML? _________________________________________33
Why Use the UML? ________________________________________34
The Class Diagram _________________________________________35
Interaction Diagrams_______________________________________42
Summary_________________________________________________45
Review Questions _________________________________________45

PART II
The Limitations of Traditional Object-Oriented
Design ________________________________________________47

Chapter 3
A Problem That Cries Out for Flexible Code ____49
Overview_________________________________________________49
Extracting Information from a CAD/CAM System _____________49
Understand the Vocabulary _________________________________50
Describe the Problem ______________________________________52
The Essential Challenges and Approaches_____________________55
Summary_________________________________________________58
Review Questions _________________________________________59

Chapter 4
A Standard Object-Oriented Solution_____________61
Overview_________________________________________________61
Solving with Special Cases __________________________________61
Summary_________________________________________________70
Review Questions _________________________________________71
 Contents xi

PART III
Design Patterns _____________________________________73

Chapter 5
An Introduction to Design Patterns ______________75
Overview_________________________________________________75
Design Patterns Arose from Architecture and Anthropology ____76
Moving from Architectural to Software Design Patterns ________81
Why Study Design Patterns? _______________________________83
Other Advantages of Studying Design Patterns ________________88
Summary_________________________________________________90
Review Questions _________________________________________90

Chapter 6
The Facade Pattern ________________________________93
Overview_________________________________________________93
Introducing the Facade Pattern ______________________________93
Learning the Facade Pattern ________________________________94
Field Notes: The Facade Pattern _____________________________97
Relating the Facade Pattern to the CAD/CAM Problem _________99
Summary_________________________________________________99
Review Questions _________________________________________99

Chapter 7
The Adapter Pattern _______________________________101
Overview________________________________________________101
Introducing the Adapter Pattern____________________________101
Learning the Adapter Pattern ______________________________102
Field Notes: The Adapter Pattern ___________________________107
Relating the Adapter Pattern to the CAD/CAM Problem _______111
Summary _______________________________________________112
Review Questions ________________________________________112
xii Contents

Chapter 8
Expanding Our Horizons __________________________115
Overview________________________________________________115
Objects: The Traditional View and the New View _____________117
Encapsulation: The Traditional View and the New View _______119
Find What Is Varying and Encapsulate It ____________________123
Commonality and Variability Analysis and Abstract Classes ____127
The Qualities of Agile Coding ______________________________130
Summary _______________________________________________135
Review Questions ________________________________________136

Chapter 9
The Strategy Pattern ______________________________139
Overview________________________________________________139
An Approach to Handling New Requirements________________139
The International E-Commerce System Case Study:
Initial Requirements __________________________________142
Handling New Requirements ______________________________143
The Strategy Pattern ______________________________________152
Field Notes: Using the Strategy Pattern ______________________154
Summary _______________________________________________156
Review Questions ________________________________________157

Chapter 10
The Bridge Pattern ________________________________159
Overview________________________________________________159
Introducing the Bridge Pattern _____________________________159
Learning the Bridge Pattern: An Example ___________________161
An Observation About Using Design Patterns ________________172
Learning the Bridge Pattern: Deriving It _____________________173
The Bridge Pattern in Retrospect ___________________________183
Field Notes: Using the Bridge Pattern _______________________183
Summary _______________________________________________188
Review Questions ________________________________________191
 Contents xiii

Chapter 11
The Abstract Factory Pattern ____________________193
Overview________________________________________________193
Introducing the Abstract Factory Pattern ____________________193
Learning the Abstract Factory Pattern: An Example___________194
Learning the Abstract Factory Pattern: Implementing It _______202
Field Notes: The Abstract Factory Pattern ____________________207
Relating the Abstract Factory Pattern to the CAD/CAM
Problem _____________________________________________211
Summary _______________________________________________211
Review Questions ________________________________________212

PART IV
Putting It All Together: Thinking in Patterns____215

Chapter 12
How Do Experts Design? _________________________217
Overview________________________________________________217
Building by Adding Distinctions ____________________________217
Summary _______________________________________________226
Review Questions ________________________________________226

Chapter 13
Solving the CAD/CAM Problem
with Patterns ______________________________________229
Overview________________________________________________229
Review of the CAD/CAM Problem__________________________229
Thinking in Patterns ______________________________________231
Thinking in Patterns: Step 1 _______________________________233
Thinking in Patterns: Step 2a ______________________________233
Thinking in Patterns: Step 2b ______________________________239
Thinking in Patterns: Step 2c_______________________________244
Thinking in Patterns: Steps 2a and 2b Repeated (Facade) ______244
xiv Contents

Thinking in Patterns: Steps 2a and 2b Repeated (Adapter) _____245

Thinking in Patterns: Steps 2a and 2b Repeated
(Abstract Factory)_____________________________________246
Thinking in Patterns: Step 3 _______________________________246
Comparison with the Previous Solution _____________________247
Summary _______________________________________________249
Review Questions ________________________________________250

PART V
Toward a New Paradigm of Design _____________251

Chapter 14
The Principles and Strategies of Design
Patterns ____________________________________________253
Overview________________________________________________253
The Open-Closed Principle ________________________________254
The Principle of Designing from Context ____________________255
The Principle of Encapsulating Variation_____________________261
Abstract Classes vs. Interfaces ______________________________262
The Principle of Healthy Skepticism_________________________264
Summary _______________________________________________265
Review Questions ________________________________________266

Chapter 15
Commonality and Variability Analysis___________269
Overview________________________________________________269
Commonality and Variability Analysis and Application Design _269
Solving the CAD/CAM Problem with CVA ___________________270
Summary _______________________________________________277
Review Questions ________________________________________277

Chapter 16
The Analysis Matrix _______________________________279
Overview________________________________________________279
 Contents xv

In the Real World: Variations ______________________________279

The International E-Commerce System Case Study: Handling
Variation ____________________________________________280
Field Notes ______________________________________________291
Summary _______________________________________________294
Review Questions ________________________________________294

Chapter 17
The Decorator Pattern ___________________________297
Overview________________________________________________297
A Little More Detail_______________________________________297
The Decorator Pattern_____________________________________300
Applying the Decorator Pattern to the Case Study ____________301
Another Example: Input/Output ___________________________305
Field Notes: Using the Decorator Pattern ____________________307
The Essence of the Decorator Pattern _______________________309
Summary _______________________________________________310
Review Questions ________________________________________310

PART VI
Other Values of Patterns _________________________313

Chapter 18
The Observer Pattern _____________________________315
Overview________________________________________________315
Categories of Patterns _____________________________________315
More Requirements for the International E-Commerce
Case Study ___________________________________________317
The Observer Pattern _____________________________________319
Applying the Observer to the Case Study ____________________319
Field Notes: Using the Observer Pattern _____________________325
Summary _______________________________________________327
Review Questions ________________________________________328
xvi Contents

Chapter 19
The Template Method Pattern ___________________331
Overview________________________________________________331
More Requirements for the International E-Commerce
Case Study ___________________________________________331
The Template Method Pattern______________________________332
Applying the Template Method to the International
E-Commerce Case Study ______________________________333
Using the Template Method Pattern to Reduce Redundancy ___334
Field Notes: Using the Template Method Pattern______________340
Summary _______________________________________________341
Review Questions ________________________________________343

PART VII
Factories ___________________________________________345

Chapter 20
Lessons from Design Patterns: Factories _____347
Overview________________________________________________347
Factories ________________________________________________347
The Universal Context Revisited____________________________349
Factories Follow Our Guidelines____________________________351
Limiting the Vectors of Change_____________________________353
Another Way to Think About It ____________________________354
Different Roles of Factories ________________________________355
Field Notes ______________________________________________355
Summary _______________________________________________356
Review Questions ________________________________________356
Overview________________________________________________359

Chapter 21
The Singleton Pattern and the Double-Checked
Locking Pattern ___________________________________359
Introducing the Singleton Pattern __________________________360
 Contents xvii

Applying the Singleton Pattern to the Case Study ____________361

A Variant: The Double-Checked Locking Pattern _____________364
Reflections ______________________________________________367
Field Notes: Using the Singleton and Double-Checked Locking
Patterns _____________________________________________368
Summary _______________________________________________369
Review Questions ________________________________________369

Chapter 22
The Object Pool Pattern __________________________371
Overview________________________________________________371
A Problem Requiring the Management of Objects ____________372
The Object Pool Pattern ___________________________________381
Observation: Factories Can Do Much More Than Instantiation _381
Summary _______________________________________________384
Review Questions ________________________________________384

Chapter 23
The Factory Method Pattern_____________________385
Overview________________________________________________385
More Requirements for the Case Study _____________________385
The Factory Method Pattern _______________________________386
Factory Method Pattern and Object-Oriented Languages ______387
Field Notes: Using the Factory Method Pattern _______________388
Summary _______________________________________________390
Review Questions ________________________________________390

Chapter 24
Summary of Factories ____________________________393
Overview________________________________________________393
Steps in the Software Process ______________________________393
Parallels in Factories and XP Practices _______________________395
Scaling Systems __________________________________________395
xviii Contents

PART VIII
Endings and Beginnings__________________________397

Chapter 25
Design Patterns Reviewed: A Summation
and a Beginning ___________________________________399
Overview________________________________________________399
A Summary of Object-Oriented Principles ___________________400
How Design Patterns Encapsulate Implementations ___________401
Commonality and Variability Analysis and Design Patterns ____401
Decomposing a Problem Domain into Responsibilities_________402
Patterns and Contextual Design ____________________________403
Relationships Within a Pattern _____________________________404
Design Patterns and Agile Coding Practices __________________405
Field Notes ______________________________________________406
Summary _______________________________________________407
Review Questions ________________________________________408

Chapter 26
Bibliography________________________________________409
Design Patterns Explained: The Web Site Companion _________410
Recommended Reading __________________________________410
Recommended Reading for Java Programmers _______________412
Recommended Reading for C++ Programmers _______________413
Recommended Reading for COBOL Programmers ____________414
Recommended Reading on eXtreme Programming ___________414
Recommended Reading on General Programming ____________415
Personal Favorites ________________________________________415

Index ________________________________________________419
 Preface

Should You Buy the Second Edition

If You Already Own the First?

The answer, of course, is yes! Here’s why.

Since the first edition was written, we have learned so much more
about design patterns, including the following:

• How to use commonality and variability analysis to design

application architectures

• How design patterns relate to and actually facilitate eXtreme

programming (XP) and agile development.

• How testing is a first principle of quality coding.

• Why the use of factories to instantiate and manage objects is

critical

• Which set of patterns are essential for students to help them

learn how to think in patterns

This book covers all of these topics. We have deepened and clari-
fied what we had before and have added some new content that
you will find very helpful, including the following:

• Chapter 15: Commonality and Variability Analysis

• Chapter 20: Lessons from Design Patterns: Factories

• Chapter 21: The Object-Pool Pattern (a pattern not covered

by the Gang of Four)

• Chapter 22: Factories Summarized

xix
xx Preface

We have changed the order in which we present some of the pat-

terns. This sequence is more helpful for the students in our courses
as they learn the ideas behind patterns.

We have touched every chapter, incorporating the feedback we

have received from our many readers over these past three years.

And, to help students, we have created study questions for each

chapter (with answers on the book’s companion Web site).

We can honestly say this is one of the few second editions that is
definitely worth buying — even if you have the first one.

We would love to hear what you think.

—Alan and Jim

Design patterns and object-oriented programming. They hold such

promise to make your life as a software designer and developer eas-
ier. Their terminology is bandied about every day in the technical
and even the popular press. It can be hard to learn them, however,
to become proficient with them, to understand what is really going
on.

Perhaps you have been using an object-oriented or object-based lan-

guage for years. Have you learned that the true power of objects is
not inheritance, but is in “encapsulating behaviors”? Perhaps you
are curious about design patterns and have found the literature a bit
too esoteric and high-falutin. If so, this book is for you.

It is based on years of teaching this material to software developers,

both experienced and new to object orientation. It is based upon the
belief—and our experience—that when you understand the basic
principles and motivations that underlie these concepts, why they
are doing what they do, your learning curve will be incredibly short-
er. And in our discussion of design patterns, you will understand the
 Preface xxi

true mindset of object orientation, which is a necessity before you can

become proficient.

As you read this book, you will gain a solid understanding of 12 core
design patterns and a pattern used in analysis. You will learn that
design patterns do not exist in isolation, but work in concert with
other design patterns to help you create more robust applications.
You will gain enough of a foundation that you will be able to read the
design pattern literature, if you want to, and possibly discover patterns
on your own. Most importantly, you will be better equipped to cre-
ate flexible and complete software that is easier to maintain.

Although the 12 patterns we teach here are not all of the patterns you
should learn, an understanding of these will enable you to learn the
others on your own more easily. Instead of giving you more patterns
than you need to get started, we have included pattern-related is-
sues that will be more useful.

From Object Orientation to Patterns to True

Object Orientation

In many ways, this book is a retelling of my personal experience

learning design patterns. This started with learning the patterns them-
selves and then learning the principles behind them. I expanded this
understanding into the realms of analysis and testing as well as learn-
ing how patterns relate to agile coding methods. This second edition
of this book includes many additional insights I have had since pub-
lication of the first edition. Prior to studying design patterns, I con-
sidered myself to be reasonably expert in object-oriented analysis
and design. My track record had included several fairly impressive de-
signs and implementations in many industries. I knew C++ and was
beginning to learn Java. The objects in my code were well-formed and
tightly encapsulated. I could design excellent data abstractions for
inheritance hierarchies. I thought I knew object orientation.
xxii Preface

Now, looking back, I see that I really did not understand the full ca-
pabilities of object-oriented design, even though I was doing things
the way most experts advised. It wasn’t until I began to learn design
patterns that my object-oriented design abilities expanded and deep-
ened. Knowing design patterns has made me a better designer, even
when I don’t use these patterns directly.

I began studying design patterns in 1996. I was a C++/object-orient-

ed design mentor at a large aerospace company in the Northwest.
Several people asked me to lead a design pattern study group. That’s
where I met my coauthor, Jim Trott. In the study group, several in-
teresting things happened. First, I grew fascinated with design pat-
terns. I loved being able to compare my designs with the designs of
others who had more experience than I. And second, I discovered
that I was not taking full advantage of designing to interfaces and
that I didn’t always concern myself with seeing whether I could have
an object use another object without knowing the used object’s type.
I also noticed that beginners in object-oriented design—those who
would normally be deemed as learning design patterns too early—
were benefiting as much from the study group as the experts were.
The patterns presented examples of excellent object-oriented designs
and illustrated basic object-oriented principles, which helped to ma-
ture their designs more quickly. By the end of the study sessions, I was
convinced that design patterns were the greatest thing to happen to
software design since the invention of object-oriented design.

When I looked at my work at the time, however, I saw that I was not
incorporating any design patterns into my code. Or, at least, not con-
sciously. Later, after learning patterns, I realized I had incorporated
many design patterns into my code just out of being a good coder.
However, now that I understand patterns better, I am able to use
them better.

I just figured I didn’t know enough design patterns yet and needed
to learn more. At the time, I only knew about six of them. Then I had
an epiphany. I was working as a mentor in object-oriented design
 Preface xxiii

for a project and was asked to create the project’s high-level design.
The leader of the project was extremely sharp, but was fairly new to
object-oriented design.

The problem itself wasn’t that difficult, but it required a great deal of
attention to make sure the code was going to be easy to maintain.
Literally, after about two minutes of looking at the problem, I had de-
veloped a design based on my normal approach of data abstraction.
Unfortunately, it was also clear to me this was not going to be a good
design. Data abstraction alone had failed me. I had to find something
better.

Two hours later, after applying every design technique I knew, I was
no better off. My design was essentially the same. What was most
frustrating was that I knew there was a better design. I just couldn’t
see it. Ironically, I also knew of four design patterns that “lived” in my
problem, but I couldn’t see how to use them. Here I was—a supposed
expert in object-oriented design—baffled by a simple problem!

Feeling very frustrated, I took a break and started walking down the
hall to clear my head, telling myself I would not think of the prob-
lem for at least 10 minutes. Well, 30 seconds later, I was thinking
about it again! But I had gotten an insight that changed my view of
design patterns: rather than using patterns as individual items, I
should use the design patterns together.

Patterns are supposed to be sewn together to solve a problem.

I had heard this before, but hadn’t really understood it. Because pat-
terns in software have been introduced as design patterns, I had always
labored under the assumption that they had mostly to do with design.
My thoughts were that in the design world, the patterns came as
pretty much well-formed relationships between classes. Then I read
Christopher Alexander’s amazing book, The Timeless Way of Building
(Oxford University Press, 1979). I learned that patterns existed at all
levels—analysis, design, and implementation. Alexander discusses
xxiv Preface

using patterns to help in the understanding of the problem domain

(even in describing it), not just using them to create the design after
the problem domain is understood.

My mistake had been in trying to create the classes in my problem do-

main and then stitch them together to make a final system, a process
that Alexander calls a particularly bad idea. I had never asked whether
I had the right classes because they just seemed so right, so obvious;
they were the classes that immediately came to mind as I started my
analysis, the “nouns” in the description of the system that we had been
taught to look for. But I had struggled trying to piece them together.

When I stepped back and used design patterns and Alexander’s ap-
proach to guide me in the creation of my classes, a far superior solu-
tion unfolded in only a matter of minutes. It was a good design, and
we put it into production. I was excited—excited to have designed a
good solution and excited about the power of design patterns. It was
then that I started incorporating design patterns into my develop-
ment work and my teaching.

I began to discover that programmers who were new to object-ori-

ented design could learn design patterns, and in doing so, develop a
basic set of object-oriented design skills. It was true for me, and it
was true for the students whom I was teaching.

Imagine my surprise! The design pattern books I had been reading and
the design pattern experts I had been talking to were saying that you
really needed to have a good grounding in object-oriented design be-
fore embarking on a study of design patterns. Nevertheless, I saw,
with my own eyes, students who learned object-oriented design con-
currently with design patterns learned object-oriented design faster
than those just studying object-oriented design. They even seemed to
learn design patterns at almost the same rate as experienced object-
oriented practitioners.
 Preface xxv

I began to use design patterns as a basis for my teaching. I began to

call my classes Pattern-Oriented Design: Design Patterns from Analysis to
Implementation.

I wanted my students to understand these patterns and began to dis-

cover that using an exploratory approach was the best way to foster
this understanding. For instance, I found that it was better to pres-
ent the Bridge pattern by presenting a problem and then have my stu-
dents try to design a solution to the problem using a few guiding
principles and strategies that I had found were present in most of the
patterns. In their exploration, the students discovered the solution—
essentially the Bridge pattern—and remembered it.

Design Patterns and Agile/XP

The guiding principles and strategies underlying design patterns

seem very clear to me now. Certainly, they are stated in the “Gang
of Four’s” design patterns book, but too succinctly to be of value
to me when I first read it. I believe the Gang of Four were writing
for the Smalltalk community, which was very grounded in these
principles and therefore needed little background. It took me a
long time to understand them because of limitations in my own
understanding of the object-oriented paradigm. It was only after
integrating in my own mind the work of the Gang of Four with
Alexander’s work, Jim Coplien’s work on commonality and vari-
ability analysis, and Martin Fowler’s work in methodologies and
analysis patterns that these principles became clear enough to me
so that I was able to talk about them to others. It helped that I
was making my livelihood explaining things to others—so I could-
n’t get away with making assumptions as easily as I could when I
was just doing things for myself.

Since the first edition of this book appeared, I have been doing a
considerable amount of agile development and have become very
grounded in eXtreme Programming (XP) coding practices, test-
driven development (TDD), and Scrum. Initially, I had a difficult
xxvi Preface

time reconciling design patterns with XP and TDD. However, I

quickly realized that both have great value and both are ground-
ed in the same principles (although they take different design ap-
proaches). In fact, in our agile software development boot camps,
we make it clear that design patterns, used properly, are strong en-
ablers of agile development.

Throughout this book, I discuss many of the ways design patterns

relate to agile management and coding practices. If you are unfa-
miliar with XP, TDD, or Scrum, do not be too concerned about
these comments. However, if this is the case, I suggest the next
book you read be about one of these topics.

In any event, I found that these guiding principles and strategies

could be used to “derive” several of the design patterns. By “derive
a design pattern,” I mean that if I looked at a problem that might be
solved by a design pattern, I could use the guiding principles and
strategies that I learned from patterns to come up with the solution
expressed in a pattern. I made it clear to my students that we weren’t
really coming up with design patterns this way. Instead, I was just il-
lustrating one possible thought process that the people who came up
with the original solutions, those that were eventually classified as de-
sign patterns, might have used.

My abilities to explain these few, but powerful, principles and strate-

gies improved. As they did, I found that it became more useful to ex-
plain an increasing number of the Gang of Four patterns. In fact, I use
these principles and strategies to explain virtually all the patterns I dis-
cuss in my design patterns course.

I found that I was using these principles in my own designs both with
and without patterns. This didn’t surprise me. If using these strate-
gies resulted in a design equivalent to a design pattern when I knew
the pattern was present, that meant they were giving me a way to
derive excellent designs (because patterns are excellent designs by
 Preface xxvii

definition). Why would I get any poorer designs from these techniques
just because I didn’t know the name of the pattern that might or might
not be present anyway?

These insights helped hone my training process (and now my writ-

ing process). I had already been teaching my courses on several lev-
els. I was teaching the fundamentals of object-oriented analysis and
design. I did that by teaching design patterns and using them to il-
lustrate good examples of object-oriented analysis and design. In ad-
dition, by using the patterns to teach the concepts of object
orientation, my students were also better able to understand the prin-
ciples of object orientation. And by teaching the guiding principles and
strategies, my students were able to create designs of comparable
quality to the patterns themselves.

I relate this story because this book follows much the same pattern
as my course (pun intended). Virtually all the material in this book
now is covered in one of our courses on design patterns, test-driven-
development or agile development best practices.1

As you read this book, you will learn the patterns. Even more impor-
tantly, you will learn why they work and how they can work together,
and the principles and strategies upon which they rely. It will be useful
to draw on your own experiences. When I present a problem in the
text, it is helpful if you imagine a similar problem that you have come
across. This book isn’t about new bits of information or new patterns to
apply, but rather a new way of looking at object-oriented software de-
velopment. I hope that your own experiences, connected with the prin-
ciples of design patterns, will prove to be a powerful ally in your learning.

Alan Shalloway
December 2000
Updated October 2004

1. See the book’s companion Web site, http://www.netobjectives.com/dpexplained, to

see more about these courses.
xxviii Preface

From Artificial Intelligence to Patterns

to True Object Orientation

My journey into design patterns had a different starting point than

Alan’s, but we have reached the same conclusions:

• Pattern-based analyses make you a more effective and efficient

analyst because they enable you to deal with your models more
abstractly and because they represent the collected experiences
of many other analysts.

• Patterns help people to learn principles of object orientation. The

patterns help to explain why we do what we do with objects.

I started my career in artificial intelligence (AI) creating rule-based ex-

pert systems. This involves listening to experts and creating models
of their decision-making processes and then coding these models into
rules in a knowledge-based system. As I built these systems, I began
to see repeating themes: In common types of problems, experts tend-
ed to work in similar ways. For example, experts who diagnose prob-
lems with equipment tend to look for simple, quick fixes first, and
then they get more systematic, breaking the problem into compo-
nent parts; in their systematic diagnosis, however, they tend to try first
inexpensive tests or tests that will eliminate broad classes of prob-
lems before other kinds of tests. This was true whether we were di-
agnosing problems in a computer or a piece of oil field equipment.

Today I would call these recurring themes patterns. Intuitively I

began to look for these recurring themes as I was designing new ex-
pert systems. My mind was open and friendly to the idea of patterns,
even though I did not know what they were.

Then, in 1994, I discovered that researchers in Europe had codified

these patterns of expert behavior and put them into a package that
they called Knowledge Analysis and Design Support (KADS). Dr. Karen
Gardner, a most gifted analyst, modeler, mentor, and human being,
 Preface xxix

began to apply KADS to her work in the United States. She extended
the European’s work to apply KADS to object-oriented systems. She
opened my eyes to an entire world of pattern-based analysis and de-
sign that was forming in the software world, in large part due to
Christopher Alexander’s work. Her book Cognitive Patterns (Cambridge
University Press, 1998) describes this work.

Suddenly I had a structure for modeling expert behaviors without

getting trapped by the complexities and exceptions too early. I was
able to complete my next three projects in less time, with less re-
work, and with greater end-user satisfaction, because

• I could design models more quickly because the patterns pre-

dicted for me what ought to be there. They told me what the es-
sential objects were and what to pay special attention to.

• I was able to communicate much more effectively with experts

because we had a more structured way to deal with the details
and exceptions.

• The patterns allowed me to develop better end-user training for

my system because the patterns predicted the most important
features of the system.

This last point is significant. Patterns help end users understand systems
because they provide the context for the system, why we are doing
things in a certain way. We can use patterns to describe the guiding
principles and strategies of the system. And we can use patterns to de-
velop the best examples to help end users understand the system.

I was hooked.

So, when a design patterns study group started at my place of em-

ployment, I was eager to go. This is where I met Alan, who had
reached a similar point in his work as an object-oriented designer
and mentor. The result is this book.
xxx Preface

Since writing the first edition, I have learned just how deeply this
approach to analysis can get into your head. I have been involved in
many different sorts of projects, many outside of software develop-
ment. I look at systems of people working together, exchanging
knowledge, exchanging ideas, living in remote places. The principles
of patterns and object orientation have stood me well here, too. Just
as in computer systems, much efficiency is to be gained by reducing
the dependencies among work systems.

I hope that the principles in this book help you in your own journey
to become a more effective and efficient analyst.

James R. Trott
December 2000
Updated October 2004

A Note About Conventions

Used in This Book

In the writing of this book, we had to make several choices about

style and convention. Some of our choices have surprised our read-
ers. So it is worth a few comments about why we have chosen to do
what we have done.

Approach Rationale

First person voice This book is a collaborative effort between two au-
thors. We debated and refined our ideas to find the
best ways to explain these concepts. Alan tried
them out in his courses, and we refined some
more. We chose to use the first person singular in
the body of this book because it enables us to tell
the story in what we hope is a more engaging and
natural style.
 Preface xxxi

Approach Rationale

Scanning text We have tried to make this book easy to scan so that
you can get the main points even if you do not read
the full body of text, or so that you can quickly find the
information you need. We make significant use of ta-
bles and bulleted lists. We provide text in the outside
margin that summarizes paragraphs. With the discus-
sion of each pattern, we provide a summary table of
the key features of the pattern. Our hope is that these
will make the book that much more accessible.

Code examples This book is about analysis and design more than
implementation. Our intent is to help you think
about crafting good designs based on the insights
and best practices of the object-oriented communi-
ty, as expressed in design patterns. One of the
challenges for all of us programmers is to avoid
going to the implementation too early, doing before
thinking. Knowing this, we have purposefully tried
to stay away from too much discussion on imple-
mentation. Our code examples may seem a bit
lightweight and fragmentary. Specifically, we never
provide error checking in the code. This is because
we are trying to use the code to illustrate concepts.
However, the book’s companion Web site, at
http://www.netobjectives.com/dpexplained, con-
tains more complete code examples from which
the fragments were extracted. Examples in C++
and C# are also present at this site.

Strategies and Ours is an introductory book. It will help you be

principles able to get up to speed quickly with design pat-
terns. You will understand the principles and strate-
gies that motivate design patterns. After reading
this book, you can go on to a more scholarly book
or a reference book. The last chapter points you to
many of the references that we have found useful.

Show breadth and We are trying give you a taste for design patterns,
give a taste to expose you to the breadth of the pattern world
but not go into depth in any of them (see the previ-
ous point).
xxxii Preface

Approach Rationale

Show breadth and We are trying give you a taste for design patterns,
give a taste (cont.) Our thought was this: If you brought someone to
the United States for a two-week visit, what would
you show that person? Maybe a few sites to help
him get familiar with architectures, communities,
the feel of cities and the vast spaces that separate
them, freeways, and coffee shops. But you would
not be able to show him everything. To fill in his
knowledge, you might choose to show him slide
shows of many other sites and cities to give him a
taste of the country. Then he could make plans for
future visits. Likewise, we are showing you the
major sites in design patterns, and then giving you
tastes of other areas, so that you can plan your
own journey into patterns.

How to Read Java Code

If You Are a C# Developer

All the code examples in this book are written in Java. If you do
not have experience with Java but can read C#, here is what you
need to know:

Java uses the words extends and implements to denote a class

that extends another class or one that implements an interface,
rather than the colon (:), which is used for both purposes in C#.

Hence, in Java, you would see

public class NewClass extends BaseClass

or
public class NewClass implements AnInterface

whereas in C#, you would see

public class NewClass : BaseClass

or
 Preface xxxiii

public class NewClass : AnInterface

All methods are virtual in Java, and therefore you don’t specify
whether they are new or overridden. There are no such key-
words in Java; all subclass methods override any methods they
reimplement from a base class. Although there are other differ-
ences, they won’t show up in our code examples.

How to Read Java Code If You Are

a C++ Developer

This is a little more difficult, but not much more. The most obvi-
ous difference is the lack of header files. But how to read the com-
bined header-code file is self-evident. In addition to the C#
differences, Java never stores objects on the stack. Java stores ob-
jects in heap storage and stores variables that hold references
(pointers) to objects on the stack. Every object must be created
with a new.

Hence, in Java you would see

MyClass anObject= new MyClass();

anObject.someMethod();

whereas in C++, you would see

MyClass *anObject= new MyClass();

anObject->someMethod();

Thus Java code looks like C++ code if you add an asterisk (*) in the
declaration of every variable name that references an object and
convert the period (.) to a hyphen followed by a right-angle brack-
et (->).
xxxiv Preface

Feedback

Design patterns are a work in progress, a conversation among prac-

titioners who discover best practices, who discover fundamental prin-
ciples in object orientation.

We value your feedback on this book:

• What did we do well or poorly?

• Are there errors that need to be corrected?

• Was there something that was confusingly written?

Please visit us at the Net Objectives companion Web site for this book;
the URL is http://www.netobjectives.com/dpexplained. At this site,
you will find our latest research as well as a discussion group relat-
ed to this book and to software development in general. Please post
corrections, comments, insights, and “aha” moments to this discus-
sion group.

New in the Second Edition

This second edition represents several changes and improvements

over the first edition. It reflects what we have learned from using and
teaching design patterns over the past several years as well as the gen-
erous and valuable feedback we have received from our readers.

Here is a highlight of changes:

• Chapter reordering (for instance, the Strategy pattern is described

earlier in the book).

• Expanded discussion about commonality and variability analysis

(CVA).

• A synthesis of eXtreme Programming (XP) and design patterns.

 Preface xxxv

• All code examples complete rather than notional or fragments.

All code is in Java. The Web site also has C# and C++ examples.

• Why the use of factories as object instantiators/managers proves

extremely helpful.

• A design pattern not in the Gang of Four: the Object Pool pattern.

• A discussion of the pitfalls of patterns, including a caution to treat

patterns as guides to help you think. Patterns are not truth!

• We also made numerous small corrections in grammar and style.

Acknowledgments

Almost every preface ends with a list of acknowledgments of those

who helped in the development of the book. We never fully appre-
ciated how true this was until doing a book of our own. Such an ef-
fort is truly a work of a community. The list of people to whom we
are in debt is long.

The following people are especially significant to us:

• Debbie Lafferty and John Neidhart from Addison-Wesley, who

never grew tired of encouraging us and keeping us on track.

• Scott Bain, our colleague who patiently reviewed this work and
gave us insights. His collaboration with Alan at Net Objectives
also led to many of the new insights in the second edition of this
book.

• Our team of reviewers: James Huddleston, Steve Metsker, and

Clifton Nock.

• And especially Leigh and Jill, our patient wives, who put up with
us and encouraged us in our dream of this book.

We received fantastic comments from so many people who reviewed

the first edition and the drafts of this present edition. We especially
xxxvi Preface

want to recognize Brian Henderson, Bruce Trask, Greg Frank, and

Sudharsan Varadharajan, who shared freely and patiently their in-
sights, suggestions, and questions.

Special thanks from Alan:

• Several of my students early on had an impact they probably

never knew. Many times during my courses, I hesitated to proj-
ect new ideas, thinking I should stick with the tried and true.
However, their enthusiasm in my new concepts when I first start-
ed my courses encouraged me to project more and more of my
own ideas into the curriculum I was putting together. Thanks to
Lance Young, Peter Shirley, John Terrell, and Karen Allen. They
serve as a constant reminder to me how encouragement can go
a long way.

• Thanks to John Vlissides for his thoughtful comments and tough

questions.

• For the second edition, I want to add thanks to Dr. Dan

Rawsthorne, another colleague at Net Objectives. His approach
to agile development has contributed to mine. Jeff McKenna’s
(another colleague) support and affirmation is also greatly ap-
preciated. I also want to thank Kim Aue, our “director of every-
thing” at Net Objectives. Her support in general has been
extremely helpful.

• Although not implying they agree or endorse anything I say here,

I also want to give special thanks to Martin Fowler, Ken
Schwaber, Ward Cunningham, Robert Martin, Ron Jeffries, Kent
Beck, and Bruce Eckel for conversations (sometimes via e-mail)
about several of these issues.

Special thanks from Jim:

• Dr. Karen Gardner, a mentor and wise teacher in patterns of

human thought.
 Preface xxxvii

• Dr. Marel Norwood and Arthur Murphy, my initial collaborators

in KADS and pattern-based analysis.

• Brad VanBeek, who gave me the space to grow in this discipline.

• Alex Sidey, who coached me in the discipline and mysteries of

technical writing.

• Sharon and Dr. Bob Foote, now teaching at West Point, who fos-
tered in me an insatiable curiosity and an abiding interest in peo-
ple. Their love and encouragement endure as patterns in me, as
a person, a husband and father, and as an analyst.

• Bill Koops and Lindy Backues, of Millennium Relief and

Development Services (www.mrds.org), for helping me see how
pattern-based approaches may even be used to help the poor and
the marginalized. They are good mates and good mentors.
This page intentionally left blank
 PART I
An Introduction
to Object-Oriented Software
Development

Part Overview

This part introduces you to a method for developing object-orient- In this part
ed software that is based on patterns—the insights and best practices
learned by designers and users over the years—and on the model-
ing language (UML) that supports this method.

I will not follow the approach of the 1980s, where developers were
simply told to “find the nouns in the requirement statements and
make them into objects.” In that approach, encapsulation was defined
as “data hiding,” and objects were defined as “things with data and
behavior used to access and manipulate those data.” This was (and
is) a limited view, constrained as it is by a focus on how to implement
objects. It is incomplete.

This part discusses a version of the object-oriented paradigm that is

based on an expanded definition of these concepts. These expanded
definitions are the result of strategies and principles that arise from
the study of design patterns. It reflects a more complete mindset of
object orientation.

Chapter Discusses These Topics

1 The Object-Oriented Paradigm

An introduction to the latest understanding of objects.

2 The UML (Unified Modeling Language)

The UML gives us the tools to describe object-oriented de-
signs in a graphical, more readily understood manner.

1
This page intentionally left blank
 CHAPTER 1

The Object-Oriented
Paradigm

Overview

This chapter introduces you to the object-oriented paradigm by com- In this chapter
paring and contrasting it with something familiar: standard struc-
tured programming.

The object-oriented paradigm grew out of a need to meet the chal-

lenges of past practices using standard structured programming. By
being clear about these challenges, we can better see the advantages
of object-oriented programming, as well as gain a better under-
standing of this mechanism.

This chapter will not make you an expert on object-oriented meth-

ods. It will not even introduce you to all of the basic object-orient-
ed concepts. It will, however, prepare you for the rest of this book,
which explains the proper use of object-oriented design methods as
practiced by the experts.

In this chapter

• I discuss a common method of analysis, called functional decom-

position.

• I address the problem of requirements and the need to deal with

change (the scourge of programming!).

• I describe the object-oriented paradigm and show its use in action.

• I point out special object methods.

• I provide a table of important object terminology used in this

chapter on pages 22–23.
3
4 Part I • An Introduction to Object-Oriented Software Development

Before the Object-Oriented Paradigm:

Functional Decomposition

Functional Let’s start by examining a common approach to software development.

decomposition is a If I were to give you the task of writing code to access a description of
natural way to deal shapes that were stored in a database and then display them, it would
with complexity be natural to think in terms of the steps required. For example, you
might think that you would solve the problem by doing the following:

1. Locate the list of shapes in the database.

2. Open up the list of shapes.

3. Sort the list according to some rules.

4. Display the individual shapes on the monitor.

You could take any one of these steps and break it down further into
the steps required to implement it. For example, you could break
down Step 4. For each shape in the list, do the following:

4a. Identify the type of shape.

4b. Get the location of the shape.

4c. Call the appropriate function that will display the shape, giv-
ing it the shape’s location.

This is called functional decomposition because the analyst breaks down

(decomposes) the problem into the functional steps that compose it.
You and I do this because it is easier to deal with smaller pieces than
it is to deal with the problem in its entirety. It is the same approach
I might use to write a recipe for making lasagna, or instructions to
assemble a bicycle. We use this approach so often and so naturally
that we seldom question it or ask whether other alternatives exist.

One problem with functional decomposition is that it usually leads to

having one “main” program that is responsible for controlling its
 Chapter 1 • The Object-Oriented Paradigm 5

subprograms. It is a natural outcome of decomposing functions into The challenge with

smaller functions. However, it saddles the main program with too this approach: With
much responsibility: ensuring everything is working correctly, coor- great power comes
dinating and sequencing functions. Often, therefore, it results in very great responsibility
complicated code. How much easier it would be to make some of those
subfunctions responsible for their own behavior, to be able to tell the
function to go do something and trust that it will know how to do it.
Successful generals in the field and parents in the home have learned
this lesson. Programmers are learning it as well. It is called delegation.

Another problem with functional decomposition is that it does not The challenge with
help us prepare the code for possible changes in the future, for a this approach:
graceful evolution. When change is required, it is often because I Dealing with change
want to add a new variation to an existing theme. For example, I
might have to deal with new shapes or new ways to display shapes.
If I have put all the logic that implements the steps into one large
function or module, virtually any change to the steps will require
changes to that function or module.

And change creates opportunities for mistakes and unintended con-

sequences. Or, as I like to say,

Many bugs originate with changes to code.

Verify this assertion for yourself. Think of a time when you wanted
to make a change to your code, but were afraid to put it in because
you knew that modifying the code in one place could break it some-
where else. Why might this happen? Must the code pay attention to
all of its functions and how they might be used? How might the
functions interact with one another? Were there too many details for
the function to pay attention to, such as the logic it was trying to
implement, the things with which it was interacting, the data it was
using? Just as with people, programs trying to focus on too many
things simultaneously beg for errors when anything changes.
Programming is a complex, abstract, dynamic activity.
6 Part I • An Introduction to Object-Oriented Software Development

And no matter how hard you try, no matter how well you do your
analysis, you can never get all of the requirements from the user. Too
much is unknown about the future. Things change. They always do…

And nothing you can do will stop change. But you do not have
to be overcome by it.

The Problem of Requirements

Requirements Ask software developers what they know to be true about the re-
always change quirements they get from users. They often answer the following:

• Requirements are incomplete.

• Requirements are usually wrong.

• Requirements (and users) are misleading.

• Requirements do not tell the whole story.

One thing you will never hear is, “Not only were our requirements
complete, clear, and understandable, but they laid out all of the func-
tionality we were going to need for the next five years!”

In my 30 years of experience writing software, the main thing I have

learned about requirements is that requirements always change.

I have also learned that most developers think this is a bad thing. But
few of them write their code to handle changing requirements well.

Requirements change for a very simple set of reasons:

• The users’ view of their needs changes as a result of their discussions

with developers and from seeing new possibilities for the software.

• The developers’ view of the users’ problem domain changes as

they develop software to automate it and thus become more fa-
miliar with it.
 Chapter 1 • The Object-Oriented Paradigm 7

I May Not Know What Will Change,

But I Can Guess Where

Early in my career, I had a mentor who used to say, “There is al-

ways time to program it right the second time, so you might as well
do it right the first time!” I have often thought about that advice.
I used to think it meant trying to anticipate every change that
might be made and building my code accordingly. This was over-
whelming and usually disappointing because I rarely could predict
every possible change that might come my way.

Finally I realized that although I could not predict what changes

might occur, I could usually anticipate where the changes might
occur. One of the great benefits of object orientation is that I can
contain those areas of change and thus insulate my code from the
effects of change more easily.

The environment in which the software is being developed changes.

(Who anticipated, five years ago, Web development as it is today?)

This does not mean you and I can give up on gathering good re-
quirements. It does mean that we must write our code to accom-
modate change. It also means we should stop beating ourselves up
(or our customers, for that matter) for things that will naturally occur.

Change Happens! Deal With It

In all but the simplest cases, requirements will always change, no

matter how well we do the initial analysis!

Rather than complaining about changing requirements, we should

change the development process so that we can address change
more effectively.

You can design your code so that the impact of changing require-
ments is much less dramatic. Your code may evolve or new code
can be bolted on with little impact.
8 Part I • An Introduction to Object-Oriented Software Development

Dealing with Changes:

Using Functional Decomposition

Using modularity to Look a little closer at the problem of displaying shapes. How can I
isolate variation write the code so that it is easier to handle shifting requirements?
Instead of writing one large function, I could make it more modular.

For example, in Step 4c on page 4, where I “call the appropriate func-

tion that will display the shape, giving it the shape’s location,” I could write
a module like that shown in Example 1-1.

Example 1-1 Using Modularity to Contain Variation

function: display shape

input: type of shape, description of shape
action:
switch (type of shape)
case square: put display function for square here
case circle: put display function for circle here

Problems with Then, when I receive a requirement to be able to display a new type
modularity in a of shape—a triangle, for instance—I only need to change this mod-
functional ule (hopefully!).
decomposition
approach This approach presents some problems, however. For example, I said
that the inputs to the module were the type of shape and a descrip-
tion of the shape. Depending upon how I am storing shapes, it may
or may not be possible to have a consistent description of shapes that
will work well for all shapes. What if the description of the shape is
sometimes stored as an array of points and sometimes is stored an-
other way? Would that still work?

Modularity definitely helps to make the code more understandable,

and understandability makes the code easier to maintain. But mod-
ularity does not always help code deal with all the variations it might
encounter.
 Chapter 1 • The Object-Oriented Paradigm 9

With the approach that I have used so far, I find that I have two sig- Weak cohesion, tight
nificant problems, which go by the terms weak cohesion and tight cou- coupling
pling. In his book Code Complete (Microsoft Press, 1993), Steve
McConnell gives an excellent description of both cohesion and cou-
pling. He says:

Cohesion refers to how “closely the operations in a routine

are related.”1

I have heard other people refer to cohesion as clarity because the

more that operations are related in a routine (or a class), the easier
it is to understand things. Weakly cohesive classes are those that do
many, unrelated tasks. The code often appears to be a confused mass.
Taken to an extreme, these classes become entangled with most
everything in a system. I have heard some people call these god ob-
jects, because they do everything (or perhaps it’s because only God
can understand them).

Coupling refers to “the strength of a connection between two

routines. Coupling is a complement to cohesion. Cohesion de-
scribes how strongly the internal contents of a routine are re-
lated to each other. Coupling describes how strongly a routine
is related to other routines. The goal is to create routines with
internal integrity (strong cohesion) and small, direct, visible,
and flexible relations to other routines (loose coupling).”2

Most programmers have had the experience of making a change to Changing a

a function or piece of data in one area of the code that then has an function, or even
unexpected impact on other pieces of code. This type of bug is called data used by a
an unwanted side effect. That is because although we get the impact we function, can wreak
havoc on other
functions
1. McConnell, S. Code Complete: A Practical Handbook of Software Construction,
Redmond: Microsoft Press, 1993, p. 81. (Note: McConnell did not invent these
terms, Yourdon and Constantine did. We just happen to like his definitions best.)

2. Ibid, p. 87.