Programming Books C Java PHP Python Learn more Browse Programming Books
Design Patterns Explained: A New Perspective on Object-Or... and over one million other books are available for Amazon Kindle. Learn more
  • List Price: $59.99
  • Save: $42.00 (70%)
Rented from Amazon Warehouse Deals
To Rent, select Shipping State from options above
Due Date: May 27, 2015
FREE return shipping at the end of the semester. Access codes and supplements are not guaranteed with rentals.
+ $3.99 shipping
Used: Very Good | Details
Condition: Used: Very Good
Comment: ***VERY GOOD***Contains one or two pages of minor writing or highlights, and Underlines. Legible and in good shape. Minor to slightly heavy wears on cover from warehouse shelves. (Used so may not contain codes/CDs/Inserts that is included with the book.)
Access codes and supplements are not guaranteed with used items.
Qty:1
  • List Price: $59.99
  • Save: $15.57 (26%)
In Stock.
Ships from and sold by Amazon.com.
Gift-wrap available.
Sell yours for a Gift Card
We'll buy it for $12.47
Learn More
Trade in now
Have one to sell? Sell on Amazon
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition) Paperback – October 22, 2004

ISBN-13: 978-0321247148 ISBN-10: 0321247140 Edition: 2nd

Buy New
Price: $44.42
Rent
Price: $17.99
36 New from $36.31 20 Used from $24.48
Rent from Amazon Price New from Used from
Kindle
"Please retry"
Paperback
"Please retry"
$17.99
$44.42
$36.31 $24.48
Free Two-Day Shipping for College Students with Amazon Student Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student


Frequently Bought Together

Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition) + Design Patterns: Elements of Reusable Object-Oriented Software + Head First Design Patterns
Price for all three: $133.39

Buy the selected items together
NO_CONTENT_IN_FEATURE

Shop the new tech.book(store)
New! Introducing the tech.book(store), a hub for Software Developers and Architects, Networking Administrators, TPMs, and other technology professionals to find highly-rated and highly-relevant career resources. Shop books on programming and big data, or read this week's blog posts by authors and thought-leaders in the tech industry. > Shop now

Product Details

  • Paperback: 480 pages
  • Publisher: Addison-Wesley Professional; 2 edition (October 22, 2004)
  • Language: English
  • ISBN-10: 0321247140
  • ISBN-13: 978-0321247148
  • Product Dimensions: 7.1 x 1 x 9.2 inches
  • Shipping Weight: 2 pounds (View shipping rates and policies)
  • Average Customer Review: 4.2 out of 5 stars  See all reviews (57 customer reviews)
  • Amazon Best Sellers Rank: #243,713 in Books (See Top 100 in Books)

Editorial Reviews

From the Inside Flap

Should you buy the second edition if you already own the first?

The answer, of course, is yes! Let us tell you why.

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

·       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 is essential for students to help them learn how to think in patterns

All of these topics are covered in this book. We have deepened and clarified what we had before and we have added some new content that you will find very helpful, including:

·       Chapter 15: Commonality and Variability Analysis

·       Chapter 20: Lessons From Design Patterns: Factories

·       Chapter 21: The Object-Pool Pattern (this is 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 last three years.

And, to help students, we have created study questions for each chapter (with answers on the book’s companion website).

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. Theyhold such promise to make your life as a software designer and developereasier. Their terminology is bandied about every day in the technical and eventhe popular press. But it can be hard to learn them, to become proficient withthem, to understand what is really going on.

Perhaps you have been using an object-oriented or object-basedlanguage for years. Have you learned that the true power of objects is notinheritance but is in “encapsulating behaviors”? Perhaps you arecurious about design patterns and have found the literature a bit too esotericand high-falutin. If so, this book is for you.

It is based on years of teaching this material to softwaredevelopers, both experienced and new to object orientation. It is based uponthe belief—and our experience—that once you understand the basicprinciples and motivations that underlie these concepts, why they are doingwhat they do, your learning curve will be incredibly shorter. And in ourdiscussion of design patterns, you will understand the true mindset of objectorientation, which is a necessity before you can become proficient.

As you read this book, you will gain a solid understanding oftwelve core design patterns and a pattern used in analysis. You will learn thatdesign patterns do not exist in isolation, but work in concert with otherdesign patterns to help you create more robust applications. You will gain enoughof a foundation that you will be able to read the design pattern literature, ifyou want to, and possibly discover patterns on your own. Most importantly, youwill be better equipped to create flexible and complete software that is easierto maintain.

Although the twelve patterns we teach here are not all of thepatterns you should learn, an understanding of these will enable you to learnthe others on your own more easily. Instead of giving you more patterns thanyou need to get started, we have included pattern-related issues that will bemore useful.

From Object Orientation to Patterns to True Object Orientation

In many ways, this book is a retelling of my personalexperience learning design patterns. This started with learning the patternsthemselves and then learning the principles behind them. I expanded thisunderstanding into the realms of analysis and testing as well as learning howpatterns relate to agile coding methods. The second edition includes manyadditional insights I have had since publication of the first edition. Prior tostudying design patterns, I considered myself to be reasonably expert inobject-oriented analysis and design. My track record had included severalfairly impressive designs and implementations in many industries. I knew C++and was beginning to learn Java. The objects in my code were well-formed andtightly encapsulated. I could design excellent data abstractions forinheritance hierarchies. I thought I knew object-orientation.

Now, looking back, I see that I really did not understand thefull capabilities of object-oriented design, even though I was doing things theway most experts advised. It wasn’t until I began to learn designpatterns that my object-oriented design abilities expanded and deepened.Knowing design patterns has made me a better designer, even when I don’tuse these patterns directly.

I began studying design patterns in 1996. I was a C++/object­-orienteddesign mentor at a large aerospace company in the Northwest. Several peopleasked me to lead a design pattern study group. That’s where I met myco-author, Jim Trott. In the study group, several interesting things happened.First, I grew fascinated with design patterns. I loved being able to compare mydesigns with the designs of others who had more experience than I. I discoveredthat I was not taking full advantage of designing to interfaces and that I didn’talways concern myself with seeing if I could have an object use another objectwithout knowing the used object’s type. I also noticed that beginners inobject-oriented design—those who would normally be deemed as learningdesign patterns too early—were benefiting as much from the study group asthe experts were. The patterns presented examples of excellent object-orienteddesigns and illustrated basic object-oriented principles, which helped tomature their designs more quickly. By the end of the study sessions, I wasconvinced that design patterns were the greatest thing to happen to softwaredesign since the invention of object-oriented design.

However, when I looked at my work at the time, I saw that I wasnot incorporating any designpatterns into my code. Or, at least, not consciously. Later, after learningpatterns, I realized I had incorporated many design patterns into my code justout of being a good coder. However, now that I understand patterns better, I amable to use them better.

I just figured I didn’t know enough design patterns yet andneeded to learn more. At the time, I only knew about six of them. Then I had anepiphany. I was working as a mentor in object-oriented design for a project andwas asked to create the project's high-level design. The leader of the projectwas extremely sharp, but was fairly new to object-oriented design.

The problem itself wasn’t that difficult, but it required agreat 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 adesign based on my normal approach of data abstraction. Unfortunately, it wasalso clear to me this was not going to be a good design. Data abstraction alonehad failed me. I had to find something better.

Two hours later, after applying every design technique I knew, Iwas no better off. My design was essentially the same. What was mostfrustrating was that I knew there was a better design. I just couldn’tsee 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—asupposed expert in object-oriented design—baffled by a simple problem!

Feeling very frustrated, I took a break and started walking downthe hall to clear my head, telling myself I would not think of the problem forat least 10 minutes. Well, 30 seconds later, I was thinking about it again! ButI had gotten an insight that changed my view of design patterns: rather thanusing 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 assumptionthat they had mostly to do with design. My thoughts were that in the designworld, the patterns came as pretty much well-formed relationships betweenclasses. Then, I read Christopher Alexander’s amazing book, TheTimeless Way of Building. I learned that patterns existed at all levels—analysis,design, and implementation. Alexander discusses using patterns to help in theunderstanding of the problem domain (even in describing it), not just usingthem to create the design after the problem domain is understood.

My mistake had been in trying to create the classes in my problemdomain and then stitch them together to make a final system, a process whichAlexander calls a particularly bad idea. I had never asked if I had the rightclasses because they just seemed so right, so obvious; they were the classesthat 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 hadstruggled trying to piece them together.

When I stepped back and used design patterns and Alexander’sapproach to guide me in the creation of my classes, a far superior solutionunfolded in only a matter of minutes. It was a good design and we put it intoproduction. I was excited—excited to have designed a good solution andexcited about the power of design patterns. It was then that I startedincorporating design patterns into my development work and my teaching.

I began to discover that programmers who were new toobject-oriented design could learn design patterns, and in doing so, develop abasic set of object-oriented design skills. It was true for me and it was truefor the students that I was teaching.

Imagine my surprise! The design pattern books I had been readingand the design pattern experts I had been talking to were saying that youreally needed to have a good grounding in object-oriented design beforeembarking on a study of design patterns. Nevertheless, I saw, with my own eyes,students who learned object-oriented design concurrently with design patternslearned object-oriented design faster than those just studying object-orienteddesign. They even seemed to learn design patterns at almost the same rate asexperienced object-oriented practitioners.

I began to use design patterns as a basis for my teaching. Ibegan to call my classes Pattern Oriented Design: Design Patterns fromAnalysis to Implementation.

I wanted my students to understand these patterns and began todiscover that using an exploratory approach was the best way to foster thisunderstanding. For instance, I found that it was better to present the Bridgepattern by presenting a problem and then have my students try to design asolution to the problem using a few guiding principles and strategies that Ihad found were present in most of the patterns. In their exploration, thestudents discovered the solution—essentially the Bridge pattern—andremembered 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.

I will discuss many of the ways design patterns relate to agile management and coding practices throughout the book. If you are not familiar 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 andstrategies could be used to “derive” several of the design patterns.By “derive a design pattern,” I mean that if I looked at a problemthat might be solved by a design pattern, I could use the guiding principlesand strategies that I learned from patterns to come up with the solution thatis expressed in a pattern. I made it clear to my students that we weren’treally coming up with design patterns this way. Instead, I was justillustrating one possible thought process that the people who came up with theoriginal solutions, those that were eventually classified as design patterns,might have used.

My abilities to explain these few, but powerful, principles andstrategies improved. As they did, I found that it became more useful to explainan increasing number of the Gang of Four patterns. In fact, I use theseprinciples and strategies to explain virtually all of the patterns I discuss inmy design patterns course.

I found that I was using these principles in my own designs bothwith and without patterns. This didn’t surprise me. If using thesestrategies resulted in a design equivalent to a design pattern when I knew thepattern was present, that meant they were giving me a way to derive excellentdesigns (since patterns are excellent designs by definition). Why would I getany poorer designs from these techniques just because I didn’t know thename of the pattern that might or might not be present anyway?

These insights helped hone my training process (and now mywriting process). I had already been teaching my courses on several levels. Iwas teaching the fundamentals of object-oriented analysis and design. I didthat by teaching design patterns and using them to illustrate good examples ofobject-oriented analysis and design. In addition, by using the patterns toteach the concepts of object orientation, my students were also better able tounderstand the principles of object orientation. And by teaching the guidingprinciples and strategies, my students were able to create designs ofcomparable quality to the patterns themselves.

I relate this story because this book follows much the samepattern as my course (pun intended). Virtually all of the material in this booknow is covered in one of our courses on Design Patterns,Test-Driven-Development or Agile Development Best Practices1.

As you read this book, you will learn the patterns. But even moreimportantly, you will learn why they work and how they can work together, andthe principles and strategies upon which they rely. It will be useful to drawon your own experiences. When I present a problem in the text, it is helpful ifyou imagine a similar problem that you have come across. This book isn’tabout new bits of information or new patterns to apply, but rather a new way oflooking at object-oriented software development. I hope that your ownexperiences, connected with the principles of design patterns, will prove to bea powerful ally in your learning.

Alan Shalloway
December, 2000

updated May, 2004

From Artificial Intelligence to Patterns to True Object Orientation

My journey into design patterns had a different startingpoint than Alan’s but we have reached the same conclusions:

·      Pattern-based analyses make you a more effective and efficientanalyst because they let you deal with your models more abstractly and becausethey 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) creatingrule-based expert systems. This involves listening to experts and creatingmodels of their decision-making processes and then coding these models intorules in a knowledge-based system. As I built these systems, I began to seerepeating themes: in common types of problems, experts tended to work in similarways. For example, experts who diagnose problems with equipment tend to lookfor simple, quick fixes first, then they get more systematic, breaking theproblem into component parts; but in their systematic diagnosis, they tend totry first inexpensive tests or tests that will eliminate broad classes ofproblems before other kinds of tests. This was true whether we were diagnosingproblems 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 newexpert systems. My mind was open and friendly to the idea of patterns, eventhough I did not know what they were.

Then, in 1994, I discovered that researchers in Europe hadcodified these patterns of expert behavior and put them into a package thatthey called Knowledge Analysis and Design Support, or KADS. Dr. KarenGardner, a most gifted analyst, modeler, mentor, and human being, began toapply KADS to her work in the United States. She extended the European’s work to apply KADS to object-orientedsystems. She opened my eyes to an entire world of pattern-based analysis anddesign that was forming in the software world, in large part due to ChristopherAlexander’s work. Her book, Cognitive Patterns (CambridgeUniversity Press, 1998), describes this work.

Suddenly, I had a structure for modeling expert behaviors withoutgetting trapped by the complexities and exceptions too early. I was able tocomplete my next three projects in less time, with less rework, and withgreater end-user satisfaction, because:

·      I could design modelsmore quickly because the patterns predicted for me what ought to be there. Theytold me what the essential objects were and what to pay special attention to.

·      I was able to communicatemuch more effectively with experts because we had a more structured way to dealwith the details and exceptions.

·      The patterns allowed meto develop better end-user training for my system because the patternspredicted the most important features of the system.

This last point is significant. Patterns help end-usersunderstand systems because they provide the context for the system, why we aredoing things in a certain way. We can use patterns to describe the guidingprinciples and strategies of the system. And we can use patterns to develop thebest examples to help end-users understand the system.

I was hooked.

So, when a design patterns study group started at my place ofemployment, I was eager to go. This is where I met Alan who had reached asimilar point in his work as an object-oriented designer and mentor. The resultis this book.

Since writing the first edition, I have learned just how deeplythis approach to analysis can get into your head. I have been involved in manydifferent sorts of projects, many outside of software development. I look at systemsof people working together, exchanging knowledge, exchanging ideas, living inremote places. The principles of patterns and object-orientation have stood mewell here, too. Just as in computer systems, there is much efficiency to begained by reducing the dependencies between work systems.

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

James R. Trott
December, 2000

updated May, 2004

A Note About Conventions Used in This Book

In the writing of this book, we had to make severalchoices about style and convention. Some of our choices have surprised ourreaders. So, it is worth a few comments about why we have chosen to do what wehave 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 allows 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 body, 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.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 or a reference book. The last chapter will point you to many of the references that we have found useful.

Show breadth and give a taste

We are trying to 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).

 

Our thought was this: If you brought someone to the USA for a two-week visit, what would you show them? Maybe a few sites to help them 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 them everything. To fill in their knowledge, you might choose to show them slide shows of many other sites and cities to give them a taste of the country. Then, they could make plans for future visits. 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 of 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

 

while 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();

 

while in C++ you’d see:

 

MyClass *anObject= new MyClass();

anObject->someMethod();

 

Thus, Java code looks like C++ code if you add a ‘*’ in the declaration of every variable name that references an object and convert the ‘.’ to a ‘->’.

Feedback

Design patterns are a work in progress, a conversationamong practitioners who discover best practices, who discover fundamentalprinciples 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?

·

New in the Second Edition

This second edition represents several changes andimprovements over the first edition. It reflects what we have learned fromusing and teaching design patterns over the last several years as well as thegenerous and valuable feedback we have received from our readers.

Here is a highlight of changes:

·      Reorders chapters, moving the Strategy pattern earlier

·      Expands the discussion about Commonality and Variability Analysis(CVA)

·      Adds a synthesis of eXtreme Programming and design patterns

·      Makes all code examples complete rather than notional orfragments. All code is in Java. The website also has C# and C++ examples

·      Explains why the use of factories as objectinstantiators/managers is extremely useful.

·      Added one design pattern not in the Gang of Four: the Object Poolpattern.

·      Added a discussion of the pitfalls of patterns and the caution totreat patterns as guides to help you think. Patterns are not truth!

We also made numerous small corrections in grammar andstyle.

From the Back Cover

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


© Copyright Pearson Education. All rights reserved.


More About the Author

Alan Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design (see http://www.netobjectives.com/resources for useful information on these and other topics). He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas. Alan has developed training and coaching methods for Lean-Agile that have helped Net Objectives' clients achieve long-term, sustainable productivity gains.

Alan is a popular speaker at prestigious conferences worldwide. He is the primary author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Pocket Guide for Scrum Teams, Lean-Agile Software Development: Achieving Enterprise Agility and Essential Skills for the Agile Developer.

Alan has worked in dozens of industries over his career. He is a co-founder and board member for the Lean Software and Systems Consortium. He has a Masters in Computer Science from M.I.T. as well as a Masters in Mathematics from Emory University.

Follow Alan on twitter @alshalloway

Customer Reviews

The book is very well written and easy to read.
Nicholas Roeder
I would highly recommend this book as a good primer for the GoF book and for anyone who is interested in Design Patterns.
Amazon Customer
This book is an excellent introduction to Design patterns.
Munin Puh

Most Helpful Customer Reviews

Format: Paperback
Trying to understand design patterns based on most texts can be as painful as poking yourself in the eye. The book Design Patterns Explained - A New Perspective on Object-Oriented Design (2nd Edition) by Alan Shalloway and James R. Trott is considerably easier on your eye and your pain threshold...

Chapter List:

Part 1 - An Introduction to Object-Oriented Software Development: The Object-Oriented Paradigm; The UML - The Unified Modeling Language

Part 2 - The Limitations of Traditional Object-Oriented Design: A Problem That Cries Out for Flexible Code; A Standard Object-Oriented Solution

Part 3 - Design Patterns: An Introduction to Design Patterns; The Facade Pattern; The Adapter Pattern; Expanding Our Horizons; The Strategy Pattern; The Bridge Pattern; The Abstract Factory Pattern

Part 4 - Putting It All Together - Thinking In Patterns: How Do Experts Design?; Solving the CAD/CAM Problem with Patterns

Part 5 - Toward a New Paradigm of Design: The Principles and Strategies of Design Patterns; Commonality and Variability Analysis; The Analysis Matrix; The Decorator Pattern

Part 6 - Other Values Of Patterns: The Observer Pattern; The Template Method Pattern

Part 7 - Factories: Lessons from Design Patterns - Factories; The Singleton Pattern and the Double-Checked Locking Pattern; The Object Pool Pattern; The Factory Method Pattern; Summary of Factories

Part 8 - Endings and Beginnings: Design Patterns Reviewed - A Summation and a Beginning; Bibliography; Index

The traditional definitive text for design patterns was written by the Gang of Four. It goes into great detail, but it can be very abstract and hard to put into practical terms for beginners.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
49 of 53 people found the following review helpful By DP guy on December 19, 2004
Format: Paperback
I read the first edition of the book and was greatly pleased by it. I loved the way it described the reasons patterns were good. In other words, although it clearly explained the patterns in the book, it also explained the underlying approach used by the people who wrote the software that later became described as patterns. The book helped me think like these developers instead of just using solutions they had come up with.

I also liked the way the authors showed how to use the patterns in the real world. I had always thought you used the patterns as solutions to recurring problems. However, the authors described how the patterns were really about a new way to think of the problem you had to solve.

As good as the first edition was, however, it left some gaps. In particular, while the domain analysis approach they espouse called commonality - variability analysis looks great, not enough information on how to actually use it was presented. Also, as XP has become more popular, I had been wondering about how patterns and XP fit into things.

The book addresses these and some additional issues incredibly well. (...)

Overall, I give this 2 thumbs up and recommend reading it even if you've read the first one. It is a much more involved book than the first with new chapters and improvements on the existing ones.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
21 of 22 people found the following review helpful By Scott Powell on March 1, 2006
Format: Paperback
I already had an understanding of design patterns and OO design principals when I read this book (my review of the original GoF Design Patterns is somewhere on Amazon.com).

Honestly, when my friend suggested I read it I snickered: perhaps such a simple book could help him, but I already understood patterns.

But the book did a really nice job of explaining patterns. I'd be lying if I said it didn't help my understanding of some classic patterns. And I appreciated the references to the original Design Pattners book, which was written for a very technical audience and, accordingly, can be hard to understand for more novice developers.

So I'd disagree with the other reviewer who suggested just getting the GoF book. It's hard to follow, with very dated examples. I can't say about his Head First recommendation.

The book could be improved. Perhaps fewer pages comparing system architecture to structural architecture.

But overall, a good effort.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
21 of 24 people found the following review helpful By Jason on November 5, 2004
Format: Paperback Verified Purchase
I don't write reviews often but this book was so good that I felt compelled to do so. It's not just a book about design patterns but also about the thought processes that lead to them. After reading this book (the 2nd edition), I was able to find and fix the flaws I knew I had in one of my existing program designs. By learning to isolate concepts that vary, you can create loosley coupled designs that are easy to modify and extend. Thinking in patterns allows you to see the bigger picture in your design without getting caught up in the details. By having a more conceptual view of your software, you can borrow ideas from time tested solutions.

Highly Recommended!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
9 of 9 people found the following review helpful By Panit Tuangsuwan on December 19, 2005
Format: Paperback
I think "... the best thing about this book is the way the book explains their concepts..." I'm not a native-English speaker, but I felt that "I have no difficulty reading this book at all". The author walks you through cover-to-cover by "Explain You Bit by Bit". That was how I loved this book.

I'm a computer science student. I studied every classic pattern of Gang of Four (GoF), 23 patterns, in my Design Pattern course. In our course, we were using the GoF's classic book, "Design Patterns: Elements of Reusable Object-Oriented Software". Even, from the course, I got fascinated, and well-understanding of what all patterns structures are, but I still felt that I could not take full advantages of my software designing. Until I found this book, it took me to the depth of Design Patterns!

I read this book from the first page through the last. I found it Easy-to-Read!!! Even you have no idea of Object-Oriented (O-O) concept at all, you still can read this book. It briefly explains O-O paradigm and UML in the first two chapters. I, who already know O-O, also like them very much. Reading first two chapters helps me review my understanding of O-O and UML very well. The book also shows benefits of using O-O in changing environment (when the system requirements are changing over time).

Then, authors explain design patterns. In every explanation of each Design Pattern, the book gives Intent, Problem, Solution, Consequences, (UML) Diagram, and Implementation. I love the way the book is written. Reading the book makes you feel like you are personally talking to the authors. In each pattern, the author first gave you a problem to exercise your brain. Then, he shows the mistakes that some developers made normally.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Recent Customer Reviews


What Other Items Do Customers Buy After Viewing This Item?