Design Patterns Explained: A New Perspective on Object-Oriented Design (Software Pattern Series) / Edition 2

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $19.42
Usually ships in 1-2 business days
(Save 67%)
Other sellers (Paperback)
  • All (18) from $19.42   
  • New (6) from $43.28   
  • Used (12) from $19.42   

Overview

"One of the great things about the book is the way the authors explain concepts very simply using analogies rather than programming examples—this has been very inspiring for a product I'm working on: an audio-only introduction to OOP and software development."

—Bruce Eckel

"...I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely. Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns books."

—James Noble

Leverage the quality and productivity benefits of patterns—without the complexity! Design Patterns Explained, Second Edition is the field's simplest, clearest, most practical introduction to patterns. Using dozens of updated Java examples, it shows programmers and architects exactly how to use patterns to design, develop, and deliver software far more effectively.

You'll start with a complete overview of the fundamental principles of patterns, and the role of object-oriented analysis and design in contemporary software development. Then, using easy-to-understand sample code, Alan Shalloway and James Trott illuminate dozens of today's most useful patterns: their underlying concepts, advantages, tradeoffs, implementation techniques, and pitfalls to avoid. Many patterns are accompanied by UML diagrams.

Building on their best-selling First Edition, Shalloway and Trott have thoroughly updated this book to reflect new software design trends, patterns, and implementation techniques. Reflecting extensive reader feedback, they have deepened and clarified coverage throughout, and reorganized content for even greater ease of understanding. New and revamped coverage in this edition includes

  • Better ways to start "thinking in patterns"
  • How design patterns can facilitate agile development using eXtreme Programming and other methods
  • How to use commonality and variability analysis to design application architectures
  • The key role of testing into a patterns-driven development process
  • How to use factories to instantiate and manage objects more effectively
  • The Object-Pool Pattern—a new pattern not identified by the "Gang of Four"
  • New study/practice questions at the end of every chapter

Gentle yet thorough, this book assumes no patterns experience whatsoever. It's the ideal "first book" on patterns, and a perfect complement to Gamma's classic Design Patterns. If you're a programmer or architect who wants the clearest possible understanding of design patterns—or if you've struggled to make them work for you—read this book.

Read More Show Less

What People Are Saying

James Noble
"...I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely. Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns books."
Read More Show Less

Product Details

  • ISBN-13: 9780321247148
  • Publisher: Addison-Wesley
  • Publication date: 10/12/2004
  • Series: Software Patterns Series
  • Edition description: New Edition
  • Edition number: 2
  • Pages: 480
  • Sales rank: 414,683
  • Product dimensions: 7.09 (w) x 9.25 (h) x 0.98 (d)

Meet the Author

Alan Shalloway is founder, CEO, and principal consultant of Net Objectives, an object-oriented consulting and training organization. An object-oriented consultant and software developer for over 20 years, he is a frequent speaker at leading development conferences, including SD Expo, Java One, OOP, and OOPSLA. He is a certified Scrum master. He is co-author of An Introduction to XML and its Family of Technologies. Shalloway holds a master's degree in computer science from MIT.

James R. Trott currently works as a senior consultant for a large financial institution in the Pacific Northwest. He has used object-oriented and pattern-based analysis techniques throughout his 20-year career in knowledge management and knowledge engineering. He holds a master of science in applied mathematics, an MBA, and a master of arts in intercultural studies.

Read More Show Less

Read an Excerpt

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 clarified 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

We have changed the order in which we present some of the patterns. 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 easier. 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 language 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 shorter. And in our discussion of design patterns, you will understand the 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 create 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 issues 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 themselves and then learning the principles behind them. I expanded this understanding into the realms of analysis and testing as well as learning how patterns relate to agile coding methods. This second edition of this book includes many additional insights I have had since publication of the first edition. Prior to studying design patterns, I considered myself to be reasonably expert in object-oriented analysis and design. My track record had included several fairly impressive designs 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.

Now, looking back, I see that I really did not understand the full capabilities 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 deepened. 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-oriented 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 interesting things happened. First, I grew fascinated with design patterns. 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 mature 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 consciously. 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 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 developed 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 problem 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 patterns 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 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 domain 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 approach to guide me in the creation of my classes, a far superior solution 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 development work and my teaching.

I began to discover that programmers who were new to object-oriented 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 before embarking on a study of design patterns. Nevertheless, I saw, with my own eyes, students who learned object-oriented design concurrently 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.

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 discover that using an exploratory approach was the best way to foster this understanding. For instance, I found that it was better to present the Bridge pattern by presenting a problem and then have my students 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 variability 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 couldn'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 time reconciling design patterns with XP and TDD. However, I quickly realized that both have great value and both are grounded in the same principles (although they take different design approaches). In fact, in our agile software development boot camps, we make it clear that design patterns, used properly, are strong enablers of agile development.

Throughout this book, I discuss many of the ways design patterns relate to agile management and coding practices. If you are unfamiliar 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 illustrating one possible thought process that the people who came up with the original solutions, those that were eventually classified as design patterns, might have used.

My abilities to explain these few, but powerful, principles and strategies improved. As they did, I found that it became more useful to explain an increasing number of the Gang of Four patterns. In fact, I use these principles and strategies to explain virtually all the patterns I discuss 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 strategies 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 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 writing process). I had already been teaching my courses on several levels. I was teaching the fundamentals of object-oriented analysis and design. I did that by teaching design patterns and using them to illustrate good examples of object-oriented analysis and design. In addition, by using the patterns to teach the concepts of object orientation, my students were also better able to understand the principles 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 importantly, 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 development. I hope that your own experiences, connected with the principles of design patterns, will prove to be a powerful ally in your learning.

Alan Shalloway December 2000
Updated October 2004

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 expert 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 tended to work in similar ways. For example, experts who diagnose problems with equipment tend to look for simple, quick fixes first, and then they get more systematic, breaking the problem into component parts; in their systematic diagnosis, however, they tend to try first inexpensive tests or tests that will eliminate broad classes of problems before other kinds of tests. This was true whether we were diagnosing 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 expert 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, 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 design 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 rework, and with greater end-user satisfaction, because

  • I could design models more quickly because the patterns predicted for me what ought to be there. They told me what the essential 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 develop 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 employment, 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.

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 development. 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 readers. 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 authors. 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.

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 tables and bulleted lists. We provide text in the outside margin that summarizes paragraphs. With the discussion 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 community, 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 implementation. 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, contains more complete code examples from which the fragments were extracted. Examples in C++ and C# are also present at this site.

Strategies and principles

Ours is an introductory book. It will help you be able to get up to speed quickly with design patterns. You will understand the principles and strategies 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 give a taste

We are trying give you a taste for design patterns, to expose you to the breadth of the pattern world but not go into depth in any of them (see the previous point).

Show breadth and give a taste (cont.)

We are trying give you a taste for design patterns, 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

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 keywords in Java; all subclass methods override any methods they reimplement from a base class. Although there are other differences, 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 obvious difference is the lack of header files. But how to read the combined header-code file is self-evident. In addition to the C# differences, Java never stores objects on the stack. Java stores objects 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 bracket (->).

Feedback

Design patterns are a work in progress, a conversation among practitioners who discover best practices, who discover fundamental principles 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 related to this book and to software development in general. Please post corrections, comments, insights, and "aha" moments to this discussion 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 generous 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.
  • 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 appreciated how true this was until doing a book of our own. Such an effort 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 want to recognize Brian Henderson, Bruce Trask, Greg Frank, and Sudharsan Varadharajan, who shared freely and patiently their insights, 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 project new ideas, thinking I should stick with the tried and true. However, their enthusiasm in my new concepts when I first started 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 appreciated. I also want to thank Kim Aue, our "director of everything" 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.
  • 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 fostered in me an insatiable curiosity and an abiding interest in people. 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 (http://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.

Footnotes

1. See the book's companion Web site, http://www.netobjectives.com/dpexplained, to see more about these courses.

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Table of Contents

I. AN INTRODUCTION TO OBJECT-ORIENTED SOFTWARE DEVELOPMENT.

1. The Object-Oriented Paradigm.

Overview.

Before the Object-Oriented Paradigm: Functional Decomposition.

The Problem of Requirements.

Dealing with Changes: Using Functional Decomposition.

Dealing with Changing Requirements.

The Object-Oriented Paradigm.

Object-Oriented Programming in Action.

Special Object Methods.

Summary.

Review Questions.

2. The UML-The Unified Modeling Language.

Overview.

What Is the UML?

Why Use the UML?

The Class Diagram.

Interaction Diagrams.

Summary.

Review Questions.

II. THE LIMITATIONS OF TRADITIONAL OBJECT-ORIENTED DESIGN.

3. A Problem That Cries Out for Flexible Code.

Overview.

Extracting Information from a CAD/CAM System.

Understand the Vocabulary.

Describe the Problem.

The Essential Challenges and Approaches.

Summary.

Review Questions.

4. A Standard Object-Oriented Solution.

Overview.

Solving with Special Cases.

Summary.

Review Questions.

III. DESIGN PATTERNS.

5. An Introduction to Design Patterns.

Overview.

Design Patterns Arose from Architecture and Anthropology.

Moving from Architectural to Software Design Patterns.

Why Study Design Patterns?

Other Advantages of Studying Design Patterns.

Summary.

Review Questions.

6. The Facade Pattern.

Overview.

Introducing the Facade Pattern.

Learning the Facade Pattern.

Field Notes: The Facade Pattern.

Relating the Facade Pattern to the CAD/CAM Problem.

Summary.

Review Questions.

7. The Adapter Pattern.

Overview.

Introducing the Adapter Pattern.

Learning the Adapter Pattern.

Field Notes: The Adapter Pattern.

Relating the Adapter Pattern to the CAD/CAM Problem.

Summary.

Review Questions.

8. Expanding Our Horizons.

Overview.

Objects: The Traditional View and the New View.

Encapsulation: The Traditional View and the New View.

Find What Is Varying and Encapsulate It.

Commonality and Variability Analysis and Abstract Classes.

The Qualities of Agile Coding.

Summary.

Review Questions.

9. The Strategy Pattern.

Overview.

An Approach to Handling New Requirements.

The International E-Commerce System Case Study: Initial Requirements.

Handling New Requirements.

The Strategy Pattern.

Field Notes: Using the Strategy Pattern.

Summary.

Review Questions.

10. The Bridge Pattern.

Overview.

Introducing the Bridge Pattern.

Learning the Bridge Pattern: An Example.

An Observation About Using Design Patterns.

Learning the Bridge Pattern: Deriving It.

The Bridge Pattern in Retrospect.

Field Notes: Using the Bridge Pattern.

Summary.

Review Questions.

11. The Abstract Factory Pattern.

Overview.

Introducing the Abstract Factory Pattern.

Learning the Abstract Factory Pattern: An Example.

Learning the Abstract Factory Pattern: Implementing It.

Field Notes: The Abstract Factory Pattern.

Relating the Abstract Factory Pattern to the CAD/CAM Problem.

Summary.

Review Questions.

IV. PUTTING IT ALL TOGETHER: THINKING IN PATTERNS.

12. How Do Experts Design?

Overview.

Building by Adding Distinctions.

Summary.

Review Questions.

13. Solving the CAD/CAM Problem with Patterns.

Overview.

Review of the CAD/CAM Problem.

Thinking in Patterns.

Thinking in Patterns: Step 1.

Thinking in Patterns: Step 2a.

Thinking in Patterns: Step 2b.

Thinking in Patterns: Step 2c.

Thinking in Patterns: Steps 2a and 2b Repeated (Facade).

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

Thinking in Patterns: Steps 2a and 2b Repeated (Abstract Factory).

Thinking in Patterns: Step 3.

Comparison with the Previous Solution.

Summary.

Review Questions.

V. TOWARD A NEW PARADIGM OF DESIGN.

14. The Principles and Strategies of Design Patterns.

Overview.

The Open-Closed Principle.

The Principle of Designing from Context.

The Principle of Encapsulating Variation.

Abstract Classes vs. Interfaces.

The Principle of Healthy Skepticism.

Summary.

Review Questions.

15. Commonality and Variability Analysis.

Overview.

Commonality and Variability Analysis and Application Design.

Solving the CAD/CAM Problem with CVA.

Summary.

Review Questions.

16. The Analysis Matrix.

Overview.

In the Real World: Variations.

The International E-Commerce System Case Study: Handling Variation.

Field Notes.

Summary.

Review Questions.

17. The Decorator Pattern.

Overview.

A Little More Detail.

The Decorator Pattern.

Applying the Decorator Pattern to the Case Study.

Another Example: Input/Output.

Field Notes: Using the Decorator Pattern.

The Essence of the Decorator Pattern.

Summary.

Review Questions.

VI. OTHER VALUES OF PATTERNS.

18. The Observer Pattern.

Overview.

Categories of Patterns.

More Requirements for the International E-Commerce Case Study.

The Observer Pattern.

Applying the Observer to the Case Study.

Field Notes: Using the Observer Pattern.

Summary.

Review Questions.

19. The Template Method Pattern.

Overview.

More Requirements for the International E-Commerce Case Study.

The Template Method Pattern.

Applying the Template Method to the International E-Commerce Case Study.

Using the Template Method Pattern to Reduce Redundancy.

Field Notes: Using the Template Method Pattern.

Summary.

Review Questions.

VII. FACTORIES.

20. Lessons from Design Patterns: Factories.

Overview.

Factories.

The Universal Context Revisited.

Factories Follow Our Guidelines.

Limiting the Vectors of Change.

Another Way to Think About It.

Different Roles of Factories.

Field Notes.

Summary.

Review Questions.

Overview.

21. The Singleton Pattern and the Double-Checked Locking Pattern.

Introducing the Singleton Pattern.

Applying the Singleton Pattern to the Case Study.

A Variant: The Double-Checked Locking Pattern.

Reflections.

Field Notes: Using the Singleton and Double-Checked Locking Patterns.

Summary.

Review Questions.

22. The Object Pool Pattern.

Overview.

A Problem Requiring the Management of Objects.

The Object Pool Pattern.

Observation: Factories Can Do Much More Than Instantiation.

Summary.

Review Questions.

23. The Factory Method Pattern.

Overview.

More Requirements for the Case Study.

The Factory Method Pattern.

Factory Method Pattern and Object-Oriented Languages.

Field Notes: Using the Factory Method Pattern.

Summary.

Review Questions.

24. Summary of Factories.

Overview.

Steps in the Software Process.

Parallels in Factories and XP Practices.

Scaling Systems.

VIII. ENDINGS AND BEGINNINGS.

25. Design Patterns Reviewed: A Summation and a Beginning.

Overview.

A Summary of Object-Oriented Principles.

How Design Patterns Encapsulate Implementations.

Commonality and Variability Analysis and Design Patterns.

Decomposing a Problem Domain into Responsibilities.

Patterns and Contextual Design.

Relationships Within a Pattern.

Design Patterns and Agile Coding Practices.

Field Notes.

Summary.

Review Questions.

26. Bibliography.

Design Patterns Explained: The Web Site Companion.

Recommended Reading.

Recommended Reading for Java Programmers.

Recommended Reading for C++ Programmers.

Recommended Reading for COBOL Programmers.

Recommended Reading on eXtreme Programming.

Recommended Reading on General Programming.

Personal Favorites.

Index.

Read More Show Less

Preface

Design patterns and object-oriented programming. They hold such promise to make your life as a software designer and developer easier. Their terminology is bandied about every day in the technical and even the popular press. But it can be hard to learn them, to become proficient with them, to understand what is really going on.

Perhaps you have been using an object-oriented or object-based language 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 once you understand the basic principles and motivations that underlie these concepts, why they are doing what they do, your learning curve will be incredibly shorter. And in our discussion of design patterns, you will understand the 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 the ten most essential design patterns. You will learn that design pat-terns do not exist on their own, but are supposed to 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 create flexibleand complete software that is easier to maintain.

From Object Orientation to Patterns to True Object Orientation

In many ways, this book is a retelling of my personal experience learning design patterns. Prior to studying design patterns, I considered myself to be reasonably expert in object-oriented analysis and design. My track record had included several fairly impressive designs 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.

Now, looking back, I see that I really did not understand the full capabilities of object-oriented design, even though I was doing things the way the experts advised. It wasn't until I began to learn design patterns that my object-oriented design abilities expanded and deepened. 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???oriented design mentor at a large aerospace company in the north-west. Several people asked me to lead a design pattern study group. That's where I met my co-author, Jim Trott. In the study group, several interesting things happened. First, I grew fascinated with design patterns. I loved being able to compare my designs with the designs of others who had more experience than I had. I discovered that I was not taking full advantage of designing to interfaces and that I didn't always concern myself with seeing if I could have an object use another object without knowing the used object's type. I noticed that beginners to 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 mature 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.

However, when I looked at my work at the time, I saw that I was not incorporating any design patterns into my code.

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 what could be called an epiphany. I was working on a project as a mentor in object-oriented design and was asked to create a high-level design for the project. 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 developed a design based on my normal approach of data abstraction. Unfortunately, it was very clear 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 problem 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 patterns 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 pat-terns came as pretty much well-formed relationships between classes. Then, I read Christopher Alexander's amazing book, The Timeless Way of Building. I learned that patterns existed at all levels—analysis, design, and implementation. Alexander discusses 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 domain and then stitch them together to make a final system, a process which Alexander calls a particularly bad idea. I had never asked if 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 approach to guide me in the creation of my classes, a far superior solution 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 development work and my teaching. I began to discover that programmers who were new to object-oriented 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 that 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 before embarking on a study of design patterns. Nevertheless, I saw, with my own eyes, that students who learned object-oriented design concurrently 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.

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 discover that using an exploratory approach was the best way to foster this understanding. For instance, I found that it was better to present the Bridge pattern by presenting a problem and then have my students 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—called the Bridge pattern—and remembered it.

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 I knew could be solved by a design pattern, I could use the guiding principles and strategies to come up with the solution that is expressed in the pattern. I made it clear to my students that we weren't really coming up with design patterns this way. Instead, I was just illustrating one possible thought process that the people who came up with the original solutions, those that were eventually classified as design patterns, might have used.

My abilities to explain these few, but powerful, principles and strategies improved. As they did, I found that it became more useful to explain an increasing number of the Gang of Four patterns. In fact, I use these principles and strategies to explain 12 of the 14 patterns I discuss 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 strategies 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 (since patterns are excellent designs by 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 writing process). I had already been teaching my courses on several levels. I was teaching the fundamentals of object-oriented analysis and design. I did that by teaching design patterns and using them to illustrate good examples of object-oriented analysis and design. In addition, by using the patterns to teach the concepts of object orientation, my students were also better able to understand the principles 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). In fact, from Chapter 3 on, this book is very much the first day of my two-day course: Pattern Oriented Design: Design Patterns from Analysis to Implementation.

As you read this book, you will learn the patterns. But even more importantly, 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 development. I hope that your own experiences, connected with the principles of design patterns, will prove to be a powerful ally in your learning.

—Alan Shalloway

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 let you 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 expert systems. This involves listening to experts and creating mod-els 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 tended to work in similar ways. For example, experts who diagnose problems with equipment tend to look for simple, quick fixes first, then they get more systematic, breaking the problem into component parts; but in their systematic diagnosis, they tend to try first inexpensive tests or tests that will eliminate broad classes of problems before other kinds of tests. This was true whether we were diagnosing 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 expert systems. My mind was open and friendly to the idea of pat-terns, 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, or KADS. Dr. Karen Gardner, a most gifted analyst, modeler, mentor, and human being, 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 design 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 rework, and with greater satisfaction by end-users, because:

  • I could design models more quickly because the patterns predicted for me what ought to be there. They told me what the essential 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 develop 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 employment, 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. 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

Read More Show Less

Customer Reviews

Average Rating 5
( 4 )
Rating Distribution

5 Star

(3)

4 Star

(1)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 4 Customer Reviews
  • Posted June 26, 2011

    Highly Recommend

    I found this book much more accessible than the GoF Patterns book. The author provides clear, easy to understand examples of how to use design patterns and when they are appropriate.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 31, 2008

    No text was provided for this review.

  • Anonymous

    Posted April 30, 2011

    No text was provided for this review.

  • Anonymous

    Posted June 30, 2010

    No text was provided for this review.

Sort by: Showing all of 4 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)