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

by Alan Shalloway (Author), James Trott (Author)

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 develop