Rating: 
Summary: Possibly the most practical textbook I've read
Review: I've been a software developer in C++ for some time. I would have to agree with the reviews that mention that most C++ textbooks rarely show the full scope and power of what this language is capable of, until you look at modern OO languages like Java and how they have been put to use. After all, those are language textbooks, not OO design/philosophy books.This book, on the other hand, made clear the "why" behind many software library architectures I've used, from the basic Java classes and AWT to things done in MFC, COM and the Stingray MFC extension libraries. Not only did it give an explanation, but it explicitly set out the "how-tos" on using these patterns yourself (complete with diagrams illustrating the structures and interactions), and more importantly when and when not to use particular patterns. For me at least, the most difficult part of designing an application is not coming up with good algorithms or efficient routines, but is constructing a sensible, easy-to-maintain architecture that will hand the demands placed on it...without writing excessively convoluted code. This seems more all the more difficult the larger the application gets. The patterns in this book clarified many things which I wish I had known earlier. A few patterns that I had "discovered" through much trial-and-error and observation were set out, often in a much cleaner form than I had come up with myself. Several of the patterns in the book were immediately applicable to a project I was working on, helping to speed through what likely would have been another messy and slow design phase. I would recommend ths book for any OO designer. At the very least, it will enable you to understand why various libraries were implemented in certain ways. At best, it will provide a useful toolkit of proven solutions enabling one to get the most out of an OO language such as C++ or Java, a toolkit that can be drawn on to solve your own architectural issues without reinventing the wheel. The only warning I would give about this book is to reiterate the warning in the preface's very first paragraph: "This book assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well. You definitely shouldn't have to rush to the nearest dictionary the moment we mention 'types' and 'polymorphism', or 'interface' as opposed to 'implementation' inheritance."
Rating: 
Summary: Use with caution
Review: There is a lot of good stuff in this book, but it needs to be used with caution. I have just spent six months attempting to work with an application framework where all of these patterns were used at every opportunity. Work was ALWAYS delegated off to some object far far away, the inheritance tree was 13 levels deep, and, whenever work actually got done, it turned out to be some code reading: Object.Execute(); Some other alarms that got triggered in me were memories of job interviews in OO environments where everyone seemed to be trying to do EVERYTHING at run-time, and nothing at compile time. They also tended to wind up with these weird generic objects and incomprehensible code. The authors specify a list of things which are "common causes of redesign" (and therefore to be avoided). Number 1 on the list is: 1. Creating an object by specifying a class explicitly. This seems to imply that any code which directly instantiates a String (e.g. in Java) is hazardous. So I am recommending caution here. Take a second look, and you might be wary of the fact that EVERYONE seems to be raving about this book. It just might be a fad.
Rating:
Summary: CD Edition is Awesome!!
Review: What you've heard is true: this is the most important book on programming of the last __ years (at least 10, for me maybe of all time). I wanted to just put a few thoughts in that I didn't see in the other reviews: 1. I read an article one time where John Vlissides (one of the authors) was saying he spoke somewhere and asked how many people had read the book and almost everyone raised their hands, then he asked, who would like to come up and explain how to implement the Composite pattern and suddenly only a couple hands were raised. Though this book is a fount of great ideas, it really will be most useful to you if you become CONVERSATIONAL with EACH of the patterns. That's the whole idea from Alexander anyway so consider it a mandate from on high. 2. One easy way I've used to explain to people what patterns are about is that mere object oriented training leaves people with an idea of how to model things as objects, but so many times I've done reviews of programmers code and they got that far and then as soon as work needed to be done that required more than one class, one of two things happens: they start passing data all over the place (back to the structured world we go), or they start binding their objects into deadly embraces. This book teaches you how to have some 'tricks' in your bag for modeling just such situations. Now, that said, there is some work you will have to do to map it into the newer programming world we're living in, for instance distributed Java makes some services available (like EJBs/container services/messaging) that changes some of the implementation ideas considerably. 3. If you are using Java, you can start to learn patterns and their application to your chosen platform by looking at a vast wealth of work that's already been done. The JDK uses the Observer pattern for its event model. Some of the more advanced frameworks, like BEA's Theory Center, are loaded w/Design Patterns (Chain of Responsibility and Strategy). And many products (Together/J) use patterns in their APIs (Visitor). Finally, whenever I'm interviewing programmers now I ask them if they know what patterns are, then if they get past that, if they can give me an example of a recent use of a pattern and how it worked. I had a guy a couple of weeks ago looking for 6 figures who told me he'd heard of the book but hadn't gotten around to opening it. Der, that's like a doctor saying 'I've heard milk might not be good for ulcers, but take it because I haven't had time to review the research yet.' More writers need to put out CD editions that are this good, dang it!!
Rating:
Summary: great book
Review: truly the bible of OO design. check out the companion book to this as well.
Rating:
Summary: BUY THIS BOOK!
Review: OK, so this title has become almost a bible for the software industry - it seems to get cited by every other author I read, so I thought it was about time I actually bought a copy. It is one of those books that has you saying 'YES!' to yourself within a few pages as the elegance and truth of the concepts become apparent, and continue saying 'YES!' to the back cover. Many of the concepts were not new to me, and it was a shock to see not a single mention of Java (because it was written before Java was invented!!). Nevertheless there is more gold in this book than in much of the rest of my bookshelf combined!
Rating:
Summary: A must if you are into oop
Review: I'm not a big fan of object oriented programming but i really enjoyed this book. It is very concise and since it presents examples it is trully exceptional! Read it man!
Rating:
Summary: The best book on OO design
Review: Definitely the best book on object oriented design. Need some knowledge of the OO paradigm and some previous experience to be really appreciated.
Rating:
Summary: Expand your programming vocabulary...difficult but worth it
Review: This is a book that you need to chew on for a while and which will take a while to digest once swallowed. It will, however, turn into pure programming muscle as payback for all your effort! This is an academic treatise (it started out as a Master's thesis) and reads like one. But as you read you'll find yourself identifying with some of the patterns that you've unknowingly used in your own code. And you'll start seeing how you could have used other patterns. And before you know it, your approach to programming has changed and you are able to focus more on the domain-specific issues rather than getting caught up in the need to continuously re-invent the proverbial wheel. And the world looks a little bit brighter. Any book that does that for you deserves 5 stars regardless of how dry it is.
Rating:
Summary: A core book for any OO programmer.
Review: In modern computer languages such as Java, creating Objects is a trivial task and almost as easy is making small numbers of Objects work together. However, there is a world of a difference between coding simple programs and developing commercial grade applications. Complexity increases exponentially. Something more is required in order to keep a handle on things. Design Patterns largely provide that answer. Initially, this book is daunting. At first I couldn't make head nor tail of what they were talking about. This revealed serious shortcomings in my own knowledge that I had to put right but once done and starting with simple patterns (such as the Singleton) things began to make sense. Persevere and there is an awful lot of knowledge to be gained here. The intelligent application of Design Patterns into complex systems pays off hansomely in the long run. My only critisisms of the book? Fairly minor really. The diagrams are all pre-UML. In fact they are they're own version of OMT diagrams. And an over reliance on Smalltalk for providing examples. In the five years this book has been published much new work has been done on Design Patterns and it's time for a new edition of the book. Nevertheless, there aren't many computing books that are five years old and still of prime relevance. This is one.
Rating:
Summary: A must read, but not a reference.
Review: Everyone who claims to write object oriented code must read this book. You will benefit greatly from it, if for no other reason than that no one will take you seriously if you don't understand its terminology. Its ideas are not revolutionary, but its method of organizing them and studying them -- patterns -- is. Patterns give common names to common design practices, making it possible to discuss them with others. If you can, borrow the book from a friend or library and read it at least once. Then decide whether you need your own copy. It should be reread every so often, as it is valuable not only for the patterns it presents, but for the systematic way in which it approaches problems. However, you do not need it on your desk to code. Indeed, it is too weighty and academic to serve as a reference. If you maintain a library of books on object oriented design, it is incomplete without this single book.
| 
