Customer Reviews

Design Patterns Explained: A New Perspective on Object-Oriented Design

5 star:		(48)
4 star:		(9)
3 star:		(4)
2 star:		(6)
1 star:		(2)

 

 

There are 2 ways of learning new concepts and principles:
1. learn principles first, then try to use them
2. observe good implementations first, then learn to appreciate the principles behind them

The authors successfully convince me that the 2nd way is the better way of learning a paradigm like OO. The authors first give us a little principles (Chapter 1), and then intorduce to us the good designs one by one (Part III, IV, V). While explaining these good design solutions (design patterns), authors didn't forget to stop and show us what we have been through, and the principles we can draw from our experience.

This is really a joyful and mind-shifting reading.

This book is not trying to teach you everything about design pattern and OO. But it lays a very sold foundation in your brain, and force you to think in a new perspective.

Of course, you should read GoF after or along with reading this one.

Also recommend:
Craig Larman: Applying UML and Design Pattern (this book puts the things you learned into real developement process)

I have read the Gang of Four book, which I highly respect and view as a kind of Bible for Patterns. The analogy is apt in that you don't read the Bible once, expecting to "get it" the first time through. You need to read, re-read, read commentaries and explainations. And even so, I found the patterns nebulous. Don't get me wrong! The G of Four book is a must have. But this is the first book that took me from the beginning to the end, explaining in concrete examples that I could understand. One of the key points is applying Patterns to the entire software process, not just design, AND MOREOVER, using many Patterns in the solution of software problems.

I also really enjoyed the writing style. Someone else has complained that it is written in first person even though there is more than one author. Personally, I don't care how many authors are involved, I want results. And the first person choice brought me into the inner circle, where someone was explaining things directly to me. It is a great read, with an almost ideal style of writing for my personality. They break out bulleted lists (another complaint from someone) that gives me the highlights of what we are going to cover. I cannot explain what a great difference that made. One great lecturer from JPL said when giving a lexture: "Tell them what you're going to tell them. Tell them. Then tell them what you told them." A brilliant speaker, this methodology lends itself to writing I think as much as speaking. Design Patterns I have read and done my best to understand, but this book breaks them down into easy to understand, and more importantly, cases where they can apply in simple language.

Possibly most importantly, they describe how learning patterns can be used together with learning OO. I have been doing OO design for many, many years. I read the GofFour, but it was soooo dry, and although I tried hard to put them into practice in my software, I was always disappointed with the results. It felt that the Patterns were tacked on to handle some specific portion of the software. This book, OTOH, addresses the issue of teaching OOD and Patterns at the same time. Even though I considered myself a "good" OO person, I found that after reading this book the Patterns began to fit together with my designs. Wonderful!

All this may not mean much to you, but if you are interested in Patterns, the Gang of Four, then please do yourself a favor and buy this book. Not only will you not regret it, it will [pull] you in and teach you in ways you never thought possible. Go for it, you will have no regrets. I have read many, many, many, software books, and this one just shines.

This sparkling little introduction to design patterns is clear, well-organized, and supplied with sufficient sample code to help you understand and use 14 of the most important design patterns. Best of all, the authors provide insight into how using design patterns meshes with best practices in object-oriented analysis and design (OOAD).

They explain the shortcomings of traditional OOAD by supplying an example of a brittle, overly complex design that they themselves had crafted. They identify the culprit as overreliance on specialization.

The authors then discuss 14 of the most important patterns from the Gang Of Four book, and how using them made their own design more elegant. Along the way, they elucidate several themes you need to know in order to use design patterns:

* Encapsulation can hide more than data. It can hide complexity (the Facade pattern) or an ill-suited interface (the Adapter pattern), for example.

* Find what is common and make it an interface; find what varies, and encapsulate it.

* Don't get lost by plunging into the details of implementation too early; instead, use design patterns to address your problem space at a conceptual level.

As suits an introductory work, the authors do not deal with all the design patterns from the Gang Of Four, and not with the same depth. Fortunately, they supply ample footnotes to provide further reading for those of us who want more depth.

Bottom Line: You know that if you just turn nouns in your problem space into objects and verbs into methods, you won't magically get a sound design. On the other hand, it is easy to get lost in the complexity of Gamma's classic. Resolve the dilemma by reading this book first!

Footnote: as I feel that the vast majority of potential readers will not have the opportunity to attend Shalloway's 2-day course, I will not use the fact that it duplicates much of the book's content as a reason to lower my rating. It's a 5-star work all the way.

I found "Design Patterns Explained" disappointing, and not worth its price, for many reasons. It has, nonetheless, some very good qualities. In the following, I'll write a detailed review starting with the disappointing features and finishing with the good qualities. I apologize if you consider this review too long for this forum.

First, "Design Patterns Explained" is very verbose without being particularly clear. The authors spend about 25% of the length of the book (the first 80 pages or so) going on and on about an alleged new perspective on object-oriented software design which is, in the end, not particularly new nor sufficiently concrete to be useful. In addition, I found the discussion of the architectural origins of design patterns to be too general and confusing for the beginner software designer.

Second, it constantly refers to the Gang of Four (GoF) book as if the authors of "Design Patterns Explained" needed confirmation of their ideas. Frankly, it tired me to the point of thinking that one might as well just read the GoF book instead. That wouldn't be a bad idea, in fact, since the GoF book is arguably the best book written so far on the subject of design patterns; its second chapter alone is worth more than "Design Patterns Explained" and is the best written, clearest, most concise (yet concrete) introduction to design patterns I have seen to this date.

Third, this book's Overview section at the beginning of each chapter is unnecessary, wasteful of paper and ink, repetitive, and downright annoying because it confuses what should be a useful summary with the listing of obvious facts about the chapter in question. For a typical example, consider the overview section of Chapter 16, "The Singleton Pattern and the Double-Checked Locking Pattern:"

"In this chapter,

* I introduce the Singleton pattern.
* I describe the key features of the Singleton pattern.
* I introduce a variant to the Singleton called the Double-Checked Locking pattern.
* I describe some of my experiences using the Singleton pattern in practice."

None of these four bulleted items says anything that the reader would not already infer from the chapter title or expect from a well written book.

And speaking of annoying features, the entire text is written in the first person, even though the book has two authors. There's nothing intrinsically wrong about that practice. It is extremely disconcerting, however, to read someone's "experiences using the Singleton pattern in practice" while not being able to determine whose experiences those are.

Next, the authors make Java their choice of language for the examples in the main body of each chapter, with C++ code at the end of each chapter. I applaud that choice, but the Java code often cannot be compiled. True, the authors admit right off the start that the code is fragmentary. But, if you're going to write a loop that uses an Enumeration, with the degree of detail that is found on page 270 (Example 17-1 on the implementation of the Observer pattern), then make sure it is complete and correct. The example just mentioned is missing the critical nextElement() call:

public void notifyObs() {
for (Enumeration e =
myObs.elements();
e.hasMoreElements() ;) {
((Observer) e).update(this);
}
}

This is not an isolated case. In addition, whenever a UML diagram contains code in a comment box, that code is written in C++, not in Java. For a typical example, refer to the bottom of p. 251, Figure 15-7, where we find statements such as component->Operation and Decorator::Operation().

For a book intended for beginners, and of this size (less than 350 pages) and cost [price], the faults I mentioned are just too many and too serious. A seasoned software designer may be able to recover quickly and painlessly from them, but a beginner trying to understand why the code cannot be compiled would surely feel frustrated.

Yet, the book is not completely devoid of qualities. Here are several:

The authors constantly emphasize the fact that requirements do change, often unexpectedly, and that a good design always anticipates those changes. Likewise, the authors advocate that designers should be proactive in their dealings with clients.

I also liked the fact that the authors always present first the obvious, often inflexible, approaches to a problem before presenting the design-pattern solution.

Another good point about this book is how the authors offer a cooperative look at the patterns discussed, often explaining how certain patterns can be used together.

Their notion of seniormost patterns constraining other patterns is also very useful and one that I had not seen in any other book. Kudos to the authors for presenting that concept.

Chapter 9 is a very clear presentation of the Bridge pattern and chapter 12, a detailed walkthrough of a case study, is likely to be very useful to the beginner software designer.

Chapter 20, "The Analysis Matrix," is probably the best contribution of this book to the toolbag of software designers, beginner and seasoned alike.

The book's website looks quite good. I've explored it briefly and have a sense that the authors tried hard to create a useful site.

In conclusion, although this book has several very good qualities, it is too unfocused and verbose, and has several serious defects, to be really useful to a beginner software designer and to justify its price. If you can get your company or someone else to pay for it, it will be a good deal. Otherwise, don't bother getting it. Instead, put the same amount of effort into reading the GoF book and you should come out a good designer.

One of my goals is to read all the books about Design Patterns. I know, it makes a very good business for some bad writters. But not here.
Honestly, when I began this book, I was just thinking about starting "Another Book to Introduce Patterns". It is. But the first thing is : it performs the job very well. Probably because the material comes from a course given by one of the author, the very nature of the patterns is very well and clearly explained, in fact the explanation outperform the one given in the GoF !! So, without any doubt, the book is O.K. for beginners, and I will recommand it as a first book on patterns (with the GoF aside ;-).
The second surprise comes from unexpected thought about patterns : relationships between GoF patterns and Alexandrian patterns and about "pattern process", or how a seniormost pattern leads to a new one. It's a simple, true and new idea exposed here. Last but not least, this book make the relationship between patterns and refactoring, and idea I support for more than one year.
Finally, the reading is very pleasant. So, why not 5 stars ? Well, I reserve this note for very rare books I found "nearly perfect" like the GoF itself...

Design Patterns Explained is a book that was recommended to me. I had always been hesitant to really investigate Design Patterns after hearing how dry most books were. Luckily, I decided to give this book a try. It was a great experience.

Summary:

Chapter 1: The Object-Oriented Paradigm
The first chapter introduces us to Functional Decomposition, handling changing requirements, and the OO Paradigm. Functional Decomposition is the process by which many developers would break down a problem and create a solution. The Authors state this is a fairly natural process that many use. They then discuss the pitfalls of this approach.

Chapter 2: The UML - The Unified Modeling Language
This chapter gives an overview of UML. Even though it is a quick chapter, the authors do a fantastic job explaining UML and how to read the diagrams.

Chapter 3: A Problem that Cries Out for Flexible Code
Chapter 4: A Standard Object-Oriented Solution
In chapter 3 the author illustrates a problem that needs to be solved, actually using an example from real world experiences. He shows us the process by which we can get a better understanding of the problem, and then how to describe and define what the problems are. In chapter 4 a solution is given and discussed. It is shown why this is a good first solution, but why it is not a good final solution.

Chapter 5: An Introduction to Design Patterns
This chapter is, as the title would indicate, an intro to Design Patterns. The origins of Design Patterns are discussed, and we find out how it was taken from Architecture and applied to software.

Chapter 6: The Facade Pattern
This chapter discusses the Facade Pattern, which is a pattern that most have probably used but not realized it. This pattern is used when you have a very complex system and only need to use a subset or part of it.

Chapter 7: The Adapter Pattern
The Adapter pattern is creating a new interface for an object whose interface just isn't doing the job. A great example is shown, and you leave the chapter understanding what the Adapter Pattern is.

Chapter 8: Expanding Our Horizons
In this chapter the authors talk about Object, Encapsulation, and Inheritance but not just in the ways you might think.

Chapter 9: The Bridge Pattern
This chapter discusses the Bridge Pattern in great detail. The authors state that this is a very difficult pattern to understand because it is extremely powerful. The two main ideas are "find what varies and encapsulate it" and "favor composition over inheritance".

Chapter 10: The Abstract Factory Pattern
This chapter starts out with an example that will that will lead to knowing what the Abstract Factory Pattern is, and then shows you how to implement it.

Chapter 11: How Do Experts Design?
In this chapter the discussion returns to the roots of Design Patterns, and discusses Christopher Alexander's approach to Architecture design. From this the authors can extend Alexander's theories and practices into the software world.

Chapter 12: Solving the CAD/CAM Problem with Patterns
Armed with the knowledge of patterns we have learned, the discussion goes in depth to show how we can use patterns to solve the same problem more efficiently.

Chapter 13: The Principles and Strategies of Design Patterns
This is a very brief chapter that covers designing from context, and encapsulating variations in classes.

Chapter 14: The Strategy Pattern
Chapter 15: The Decorator Pattern
Chapter 16: The Singleton Pattern and the Double-Checked Locking Pattern
Chapter 17: The Observer Pattern
Chapter 18: The Template Method Pattern
Chapter 19: The Factory Method Pattern
In chapters 14-19 a new case study is introduced. I am not going into specifics on each chapter because they would basically each describe the new pattern, and how it can be applied in the case study. Each chapter builds on the ideas of the one before it.

Chapter 20: The Analysis Matrix
This chapter concludes the case study in chapters 14-19 by discussing variations that occur in the problem domain. Through use of the Analysis Matrix, we can reveal patterns that manifest in the problem, and can deal with them accordingly.

Chapter 21: Design Patterns Reviewed From Our New Perspective of Object-Oriented Design
This short summation chapter takes us on a brief high-level review of key points.

Chapter 22: Bibliography
The authors give a listing of books they feel would be good further reading so you can continue your journey.

To conclude I have a few thoughts. One is that I was very impressed by the way that this book was written. It takes pretty hard concepts and breaks them down into understandable real-world examples. The ideas are very well organized, and written in such a way that anyone could understand them. The authors are adept at this, and as a result create a finished product that is one of the most well written technical books I have reviewed.

Another thing I liked about the book was that the chapter end summaries were very short, and outlined each chapter's key points perfectly. Also, the margins of the book have the key points next to the main paragraphs for each. This is a great idea because it makes looking back through the book for specific points much easier.

If I could change one thing about the book it would be to write it with VB examples in addition to the Java and C++ ones it has. Maybe by the next edition there will be some VB.net examples since VB.net is now truly Object-Oriented. Don't be scared of the book just because it has only Java and C++ examples though. They explanations of theory are so well written that the example language would not be a barrier.

I give this book a 10 out of 10. It is an excellent book, and one that is worth your while to read.

... This book is not intended for design pattern experts. Mr. Shalloway and Mr. Trott makes that very clear. It _is_ intended for any of us who had difficulties reading the Gang of Four book (actually, I suspect many people who think they understand design patterns would benefit from this book as well). I will review this book for what it is intended - an excellent introduction to design patterns.

Chapters 1 and 2 are clearly there to help those of us with minimal object-oriented design backgrounds. I consider this a value to the book and not a reason to discount its rating (just skip the chapter if you know this stuff already :)

It explains the perspective from which the developers who designed the patterns in the Gang of Four's book must have been viewing. Any of us who wondered why the Gang of Four told us to "design to interfaces" (actually, that one I understood), "encapsulate what varies" or "favor object composition over class inheritance" will get a lot out of this book.

For example:
1) designing to interfaces allows us to hide implementations
2) encapsulation is not just data-hiding, but class hiding when polymorphism is used
3) inheritance should be thought of as a way to classify, not specialize - we get reuse by containing previously developed objects
4) using object composition when possible instead of inheritance allows us to avoid large class hierarchies that are difficult to maintain

In other words, we come away not just knowing the patterns, but getting a lot of insights into why they work. Insights we can use on our own later (even when we can't identify patterns being present).

I know a lot of people who actually know patterns, but use them individually to solve particular problems. This book gives insights that I believe would help even these individuals. That is because it is as much about how to design as it is about what patterns are.

My recommendation, read this book if you want to design better.

I work in a nuclear physics experiment with a few hundred thousand lines of code, with douzens of programmers worldwide checking in code into a CVS repository and a small group of computer gurus that are the design architects of the system, being nervous every time one of us ,the mere mortal programmers, add substantial pieces of code. Now I understand why. The reason is that the gurus know about design patterns , OOD and the like, while we want to just solve problems, applying short term patches and thinking procedural. They come from a completely different point of view than the average programmer.

This book was an eye openner. After a couple of years of experience in a large scale system like that, I was able to read this book cover to cover within a few days. I cant count the times I said to myself, "Oh, now I see why they were insisting not to duplicate code like this", or "Now I understand why they were insisting to use a factory method in order to instantiate the different versions of subsystems code".

I first tried to read the GoF book. I found it pretty dry and a bit frustrating. I understood that I was reading great and important stuff but I was not completely convinced and I was left with this taste in the mouth of "I would never implement it like this, its just too complicated".
You see, you can never be convinced about something until you understand it.

And then I looked for help and I run across the "Design patterns explained" book. It really starts from the beginning, even the first few chapters -that did not teach me anything I did not know already - were a nice review on object oriented design that put everything into a context for the rest of the book.

The design patters are explained thorougly and what I really enjoyed is that in a lot of instances the pattern was not just thrown to my face but actually DERIVED from the 2 or three basic principles that the authors advocate throughout the book:

a) favor composition over inheritance
b) find what varies and encapsulate it
c) one rule,one place

Being a physicist, I thorougly enjoyed the use of a few basic principles in order to derive a new pattern.

The C++ snipets of code I must admit where pretty lame in the book, they authors didnt pay too much attention on that, but , still, for someone that knows some C++ it was easy to understand the mistakes. Besides that, the code was iluminating on how to implement a particular pattern.

Evey time that I would finish reading a pattern in this book I would go to the GoF book -the authors are kind enough to point you to the pages of the GoF book for the pattern that they explain - and it was evident that now I can understand so much better the more sophisticated and abstract GoF explanations.

I liked the book so much and it makes such a good companion to the GoF book that I cant stop searching the internet for new patterns. It is addicitve. It has made me so much better programmer, actually designer I should say.

You start this book as a programmer and you end up as a novice designer. Not experienced but enough to let you see what lies ahead. I holeharteadly recommend it.

How many books do you own? Of those, how many do you read very often? And of those, how many have the covers worn off? "Design Patterns Explained" is one of that type of book.

Very impressive and fascinating book. Very clear and easy-to-understand; anyone who programs in any language can easily follow the narrative style.

Not even mentioning the patterns for a moment, the new perspective on encapsulation, and the explanation of commonality and variability make it well worth the time to read. The idea of using abstract classes to classify concrete objects is very smart, and abstracting out commonalities in implemetation is nothing shy of genius. The patterns themselves are brilliant, of course. There will be many "oh, yeah!" moments reading the book, as if your eyes were opened. The O-O paradigm is reinforced, but also broadened. Current O-O design is made much simpler by the concepts on which the patterns rely, alone.

IMO, the reviewer's comments on the back cover about this being an intermediate text are just wrong. There's no need to learn UML first; the book works really well as an introduction to patterns, but it gives you an _extremely_ valuable new perspective on object-orientation itself... for example, instead of just using abstract classes to classify similar objects, you can abstract out the _behavior_ as its own class as well. Then, just include the appropriate concrete behavior object in the original class. This idea alone is worth the price of the book. With this information, AND the design patterns, this book's an automatic "BUY".

Advanced O-O programmers will undoubtedly find new insights into design, as well. These guys (Shalloway/Trott) absolutely know what they're talking about. How many books have we read where we thought the OPPOSITE about the author? =)Your designs will become simpler, easier to maintain and upgrade, yet more powerful.

If you're frustrated with your design approach on a current project, or you don't know where to begin... pick up this very enjoyable and EDUCATIONAL read. This is one of those that will have the covers wear off, for sure :-)

epiphany - (1)a usually sudden manifestation or perception of the essential nature or meaning of something. (3) : an illuminating discovery b : a revealing scene or moment.

The authors have written a book unlike all other design patterns books in that it fully enlightens the reader to how design patterns really work together to produce stable and robust applications. Reading other patterns books compares to looking up words in a dictionary. Reading Design Patterns Explained compares to having a famous author teach you how to think about words and how fit them together into elegant prose.

If you find other design patterns books to be difficult reading, then this is the book for you. The book is an easy read that will enlighten you to such an extent that you will be able to peruse other patterns books with relative ease.

I cannot say enough good things about the book. I only wish that it had been written five years ago.