Rating: 
Summary: The best way to really learn object-oriented design
Review: This book really changed my way of thinking about object-oriented design. The idea is that when designing a new class hierarchy, though implementation details may differ, you often find yourself using the same kinds of solutions over and over again. Rather than approaching each design task out of context as an individual, isolated problem, the strategy is to study the task and identify the underlying design pattern most likely to be applicable, and follow the class structure outlined by that pattern. It's a "cookbook" school of design that works amazingly well.There are other advantages to this book. It isolates 23 of the most common patterns and presents them in detail. You wouldn't think that 23 patterns would be enough, but once you become adept at recognizing patterns, you'll find that a large fraction of the patterns you use in practice are among these 23. For each pattern, the book carefully presents the intent of the pattern, a motivating example, consequences of using that pattern, implementation considerations and pitfalls, sample code (C++ or Smalltalk), known uses of that pattern in real-world applications, and a list of related patterns. Upon first reading, you will start to recognize these patterns in the frameworks you see. Upon second reading, you'll begin to see how these patterns can help you in your own designs, and may also start to see new patterns not listed in the book. Once you become familiar with the pattern concept, you will be able to originate your own patterns, which will serve you well in the future. One of the most valuable contributions of this book is that it is designed not merely to help you identify patterns, but to give you a sense of which patterns are appropriate in which contexts. I think this book is particularly valuable to many C++ and Java programmers, because of the dynamic and flexible design philosophy it follows. (Its two fundamental principles of reusable OO design are: "Program to an interface, not an implementation" and "Favor object composition over class inheritance".) I've found that many C++ books unfortunately tend to emphasize a rather static and inflexible design philosophy. Many C++ programmers do not realize how the language and the books they've studied from have been limiting their thinking until they have been exposed to ideas from other lanugages. The authors of this book have obviously been influenced by other languages as well, especially Smalltalk, and have brought many of its best lessons to C++ design. Most Java books seem to take after the C++ books, even though Java is a more dynamic language. This book may help Java programmers take full advantage of the extra power offered by their language, if they look deeply enough into some of the lesser-known features its runtime system affords. Last, but not least, this book is valuable because it names the patterns it uses, and so gives programmers a common vocabulary to describe design concepts, rather than particular implementations. You'll find yourself saying things like, "That would be a good use for a Decorator", or "Should we use a Facade or a Mediator in this case?" I encourage readers of this book to use this vocabulary with other programmers. In summary, this is one of the few books that I think belongs on every programmer's "must-have" list. Not to overuse a cliche, but like object-oriented design itself, the pattern concept is one of those rare paradigm-shifts in computer programming. It is equally valuable to expert professional and novice student alike. The book has a home page at http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.html
Rating:
Summary: See programming in a whole new light!
Review: I've been programming professionally for several years,
but this book opened my eyes. I'm excited to tackle
new projects using the principles I learned in this book.
The book gives complete explanations of the patterns,
reasons why you should use the different patterns,
and wonderful examples (in C++ and Smalltalk).
Buy it, learn it, live it!
Rating:
Summary: If you buy only one OO book, make it this one.
Review: If you've ever designed an OO system and fell into the same traps and gotcha's, this book will save you. The 23 design patterns detail solutions (and caveats) to some of the most common computing problems. And you'll never be without a buzzword or phrase to stymie the newbie OO developer
Rating:
Summary: One of the few books that created new fields.
Review: If you are a C++ (or any other OO language) programmer,
this book is a must.
You may already know about iterators and such, but this
book will put it all in context, giving you a new way to view
your program.
If you are not OO programer, what are you waiting for
Rating:
Summary: Don't expect anything new, but read it anyway
Review: A lot of people who work in Industry have left this book on the shelf, "because I picked it up and didn't see anything really new." That is the whole point behind this book. Design Patterns creates a common language for discussing designs that are common enough to have a core "pattern" modelled after them. By naming the patterns, old programmers will have names to express their designs so that others can understand them in a programming language independent way. If you are a new programmer, a lot of these ideas may be new to you, but if nothing is new, there is still value to this book (the now-standard names for these patterns). This book does an excellent job of elevating object oriented design discussion beyond merely talking about "inheritence" and "polymorphism", and into talking about the tradeoffs of the "Singleton" vs the "Document" pattern for global variable replacement (and why the Command pattern should always be used in multithreaded environments). That being said, if you are an experienced programmer, don't expect a lot of new material in here, feel free to skim chapters, etc. Just make sure you learn the names for the things you do every day so that the rest of the programmers on your team can understand you!
Rating: 
Summary: Fall asleep while reading this book
Review: There is nothing new here for an experienced developer. It MAY be useful for fresh graduates but I am not sure. It would be more appropriate for designers to come up with real patterns that solve real problems, not just follow patterns stated in this book, which are mostly over-kill or far away from real world. Can't understand why so many people gave it high ratings, and even more people talking about patterns with so much proud.
Rating: 
Summary: Caveat emptor
Review: This is, of course, one of the cornerstones of OOP. This book definitely influenced programmers at all levels and richly deserves the acclaim that it enjoys.
However, this book is not for everyone, especially beginners. To be able to get the best out of this book, you need some solid experience in object oriented programming. This book is ideal for people who have been developers and are moving up to designers/architects. The foundation of real world experience makes a very good base for absorbing the experience captured in this book.
This book is not theoretical by any means. In fact, it captures the experience gained by many people in the course of their careers and offers practical solutions to typical problems encountered in software engineering, specifically object oriented programming.
The material in the book is authoritative and terse and would be daunting to a newbie. Most of the explantions and examples are offered without much ado, and expect a certain level of not just knowledge from the reader but also awareness about practical applications and typical scenarios encountered in practice.
I would say that this book is suitable for full time object oriented programmers (whatever the language) with at least a couple of years of experience looking to further strengthen their knowledge of OOP systems and looking to gain an insight into the practical aspects of how to solve typical situations in real world projects.
Rating:
Summary: Now that the hype is over...
Review: ... well, it's over. "Patterns" have not revolutionized the world. Nor does this book need to be "studied" for deep insights.
What it seems patterns are actually good for is giving common names to popular solutions to problems, to make them easier to call to mind, and easier to discuss with others. Even this much is overrated. Before the advent of patterns, you could have said "callbacks" and people would have understood. Now you say "the Observer pattern".
_Design Patterns_ is none the less valuable, because it is one of those few books that EVERYONE is expected to have read. This is helpful in practice, as you can expect everyone to be familiar with its vocabulary. Few books truly fall into this "required reading" category. The only other that comes to mind is the MIT algorithms text. Many tech pundits claim that every next book is "required reading", and the claim becomes tiring after a while, but this is one of the few that really is.
I would not necessarily purchase it, though. The "pattern" schematic is verbose, and requires pages upon pages to describe something that, once you have seen it in practice once or twice, you will recogonize immediately. Omitting the appendixes, the book is barely 350 pages, and presents only 23 patterns. Only 5 or 6 of the patterns are truly famous: Singleton, Observer, Template Method... and a few more. A number of them are poorly presented. Chain of Responsibility, for instance, is just one of many ways to define an event framework and does not belong in a book that doesn't present the alternatives. Mediator is another; there must be dozens of ways to create a Mediator, which most people would call an "event registry" or something else, rather than a Mediator. "Mediator" itself is little more than a name, and won't help you in design.
Some patterns are boring, since modern languages tend to provide them, and we've heard about them many times already: Iterator, Proxy, Memento (serialization), etc. Others, like Command, are geared towards GUIs, and provide little value to other types of applications. Then there are the State and Strategy patterns, which are two sides of the same coin, and needn't be given two different names.
And so on. Definately do not "study" this book if it seems you "just don't get it". Chances are the book is wrong. It is worth a read through, and a second read through if the terminology doesn't stick the first time, but stop at that. My gut feeling is that this book is most appropriate for someone working on his or her first large project. After that, once the terminology sinks in, the book has little else to offer. And if taken dogmatically, or considered "inspired" or infallible, the book is a hindrance. Finally, overuse of patterns can result in a "kitchen sink" design, instead of a simple one that takes a few patterns, that may or may not be ones from this book, and implements them cleanly. Take the book for what it's worth, but remain skeptical.
Rating:
Summary: Required reading!
Review: This book is only for OOP black-belts, or those who wish to be.
The information in this book should be common knowledge for any software architect and in fact is required reading (along with UML Distilled, Enterprise Patterns and Refactoring, all by Martin Fowler) for anyone who wishes to advance beyond "Developer" at my company. This is must-know information for both designing systems and being able to describe those systems to others. If you look closely at any WELL DESIGNED system, you will see that it is simply of composite of the patterns in this book, implemented in a thoughtful way.
I have found few problems/issues/riddles in software design that cannot be addressed by the information in this book. It should be on EVERY serious developers bookshelf, or better yet, in their head!
Rating: 
Summary: horrible book. Very hard to read and not very explanatory.
Review: I dont understand why this book is highly praised. This book is overated. First of all, the authors give little explanation to how these patterns are used. After reading the patterns, I could not apply them to my code. The book is very hard to read. If you are going to learn about design patterns, I suggest buying head first design patterns.
|
