Rating: 
Summary: Way overrated
Review: This book serve mostly as historical note. In its time pepole use to think that "the answer" is OOP/OOD. If this book prove anything is that OOP/OOD is NOT the answer. For begginer this book is usless since they do not have the knowlage to read it and evaluate it ideas. For experience programmers this book may serve to prove that in some implemention they were using some ideas that other were using. For those with experience that realy find something new here then I think it only time for them to realized that they are very poor designers. You see in C++ you have many tools to use (and OOP is only one). This book seem to be writing by people who start to program in programming laguages that force you to use object - such as smalltalk. C++ is much more then that and now we know (I realy hope that those who are using C++ know) that OOP is just anther thing to use and not the most important one. Anther problem is that it may lead people to use those patterns in much the same way as OOP - seeing pattenrs everywhere (like many programmer who using OOP see object everywhere). Anther problem is that it like those books about "how to succeed in life in 10 steps". Well like there is no magic in being successfull (you can't realy learn how to become one) there is no way in becoming good designer. If you don't know how to design system, no book can save you. Designing good software is like art, if you don't have the gift you cannot do it - and ideas from architecture are the worst to take from. When you designing a system, look in the system that you are building for ideas and not in a book that try to solve problems that are not even there. By the way for Java/C# programmers it maybe more usefull (beacuse those lagauges only support OOP). If you are C++ programmer then learn the laguage realy well (there's much to learn), this is the only thing that will realy help you.
Rating: 
Summary: Invaluable
Review: It is to my eternal shame that I have been a computer scientist for this long, but before this January, I had never been exposed to the Gang of Four's DESIGN PATTERNS. In a few short months, the patterns I have learned from this book have become invaluable. I've already started going back through my legacy code looking for badly designed structures and have gradually been upgrading my work. If only I had known about this stuff years ago, I could have saved myself time, both during the creation of code and now, when I'm maintaining it. Software patterns are a way of preventing the programmer from reinventing the wheel. Many of the patterns discussed in this book are refinements of procedures that have been tried and tested thousands of times over the years. The idea is that by studying these prototypes, we can save ourselves time by standing on the shoulders of those noble computer scientists who came before us. And it really works too. Reading about these patterns instantly drove into my head all the places in the past where I should have been using an elegant pattern as described here, rather than the ramshackle, jury-rigged solution I created. And I even learned more about the patterns that I was already familiar with. Every Java programmer knows about, say, Iterator, but I found it fascinating to read about how powerful that little routine can be. The book is divided into three main forms of patterns: creational patterns, structural patterns and behavioral patterns. The patterns discussed span all portions of an object's life (the book is geared towards Object-Oriented Programming). We learn the best way of creating objects, the best way to have them communicate with other objects, and the best way to have them running their own algorithms. It really encourages the writing of clean code. Decoupling objects is the order of the day, and while I already knew vaguely that this was a good idea, this book showed me why exactly this is desirable, and equally importantly, it showed me how best to implement it. I was introduced to this book by enrolling in an excellent class, which walked us through the various patterns. Given that the book has a tendency towards dryness, I would recommend this learning method to anyone. The examples proposed on these pages are, perhaps, a little esoteric and can at times be obscure. Because the book was written way back in the dark ages of 1994, the sample code is written in C++ and Smalltalk; we can assume that if this same book were written today, Java would reign supreme. An instructor who has used these patterns in real applications should be able to provide the student with a plethora of easy-to-understand scenarios, to really drive home how and where these patterns should be implemented. Again, don't let the relative age fool you; get this book and take a class that explains it. If you can't find a class that teaches from this, then try to learn on your own. The skills you'll pick up from this will be immensely rewarding. Just be prepared to have the inevitable realization of: "Oh, so that's what I should have been doing all this time! Now where am I going to find the time to go back and fix it?"
Rating: 
Summary: A ground-breaking book that needs to be updated
Review: Design Patterns was originally published in 1995 and is now on its 27th reprint. It is the seminal work in Object Oriented programming. The authors have collectively made major contributions to every aspect of computer science and software development. Heck, the book is still not available in soft cover. It is well organized and greatly informative. The writing style is clear and all but novice programmers should have no problem getting through the book. But if you are buying the book to learn Java or C#, work mostly on database and web applications or are only going to buy one book on the subject, this may not be the best choice. We really need a second edition from these leaders of OO programming. The book is still 100% accurate and correct. But its contemporary audience was probably other computer scientists and experienced programmers who wanted to learn the emerging model. Accordingly, the book's code samples are in C++ and Smalltalk. The authors usually show the application of each pattern by solving problems from the GUI application development world. In 1995, designing portable windowing systems was probably the hottest project around (the Wintel world was still on 3.11 remember). Thanks in no small part to Design Patterns, developers have tackled the challenges of windowing. Now, developers are probably more focused on the Internet, database portability and web services. They are using new OO languages like Java and C# (and C++). An audience trying to work through those problems with those languages may find the book just slightly out of reach. Or at least somewhat indirect: you have to make up your own Java code samples and figure out how some of the patterns that solve GUI portability might facilitate database portability. Of course the point of the pattern is that it can be reused to solve all kinds of problems. But it's easier to learn the patterns if the book covers the problems you are trying to solve. Depending on your goal, this feedback on Design Patterns may not be a problem. The book is clearly written, informative and accurate. And if you have the budget for a great reference work, Design Patterns is still the seminal text on the subject. As a hardcover, it looks impressive on the bookshelf. Other shoppers might look for another title more applicable to their specific needs. Someone trying to learn Java, for example, might consider Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, instead. Hope this helps.
Rating: 
Summary: understanding the design pattern tools is key...
Review: First of all let me qualify my critique by saying that I use this book heavily and am grateful for it - every programmer should digest and drink in the material in this seminal and valuable book. However one must understand the boundaries of Design Patterns. Object Oriented Programming has been the New Wave of the 80's and 90's.
The initial rah-rah over encapsulation-inheritance-polymorphism faded when their benefits were hard to extract.
The design patterns are one step above O-O. Heavily founded in the the main "tricks" behind the design patterns, are also the facets of O-O
1. interface
2. dynamic binding (or polymorphism)
2. inheritance
3. aggregation (or composition) So in the future when there is the next new wave in software, I expect our paradigms to shift to something else.
In short, it is a great book, but it is not in the same league as (say) a Mathematics book which will stay current for a very, very long time. (As a Christian myself, I liked John Vlissides unashamed quotes from the Bible on the first page
Joshua 24:15 "As for me and my house, we will serve the LORD") How to read the book rapidly if you are a visually oriented person. I am a slow learner but was able to read this book in two hours:
1. First, understand intimately how the four "tricks" work, mentioned above.
2. Do not read in serial fashion from page 1 till end. Instead look at the structure diagram for a design pattern; meditate on it until you are blocked whereupon read the text to find the answer.
Rating:
Summary: A book you should read without delay
Review: I found this book to be probably the best book I've read on programming in recent times. Despite it being a bit dated, the examples convey their intended purposes without the need to be reworked to properly reflect recent changes in coding standards. One of the reasons it took me so long to read this book was because of it's publishing date which led me to believe I would be learning C++ in the wrong direction. However I was wrong and felt I wasted quite a bit of time putting this book off as long as I did. Design patterns helps you think and organize your code in such a way that once you get used to it, it's hard to see programming in any other way. You will definately become a better programmer having read this book. You will be worser without it.
Rating:
Summary: Best book on micro-level OOD design
Review: I read this book along with "Software Architecture: Perspectives on an Emerging Discipline" by Mary Shaw a few years ago. These two books have completely re-shaped way I desgin OO based software over the last few years. The "software architecture" book provides macro-level structures while the design pattern book provides micro-level implementation details. The combination of these two books provide a comprehensive view on software architeture and design. Excellent book. Order online from amazon.ca is $20 cheaper than buying it directly from chapter or indigo bookstore. Too bad I did not buy it through amazon.ca at that time, which should have been saved to buy other books :-)
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: OOD best practices classic
Review: Great book if you are a software architect with experience in designing quality software. In fact, I'd say this is the best book in the "pattern" section of the bookstore. The problem with this book (or should I say "around" this book) is that most inexperienced programmers tend to over-use patterns, specially after reading a book such as this. Patterns are a way to add clarity, reusability and simplicity to code, but when beginners use them to write down simple "hello world" programs instead of going through simpler approachs, we have a problem. Fortunately for us the "patternization" of the early 90's is gone; now patterns are use in a more rational way, and this book can be read as it was meant to be. So, you can live without this book, but it doesn't hurt to have it in your bookshelf.
Rating:
Summary: Best Patterns Book
Review: This book is still the best pattern book out there. No need to search further. This is the book that u want.
Rating:
Summary: Must have for software architects, not for head-down coders!
Review: I never thought I would be saying anything different from anybody by praising this book, that's why I never got around to writing a review for this book though I have used the concepts of this book in many projects, but recently I came across some very harsh review of this book and found that to be very very misleading, so I basically wanted to straighten things up. First of all, I would not go even near claiming this book would add value to everyone (though I might have made this very mistake had I written this review a year back), this book mainly targets the software architects who are responsible for designing large or fairly large software applications ground up, or who redesigns or enhances an existing system to make it feature rich or performance-enhanced or less unweildy (refactoring more or less). This book is just not the right stuff for head-down coders who want to remain that way. I am developing software for over 6 years, I'll say for the first three or so years I have played more of the role of a developer that the role of an architect, but then I moved on to architect position and I have found that knowledge of Design patterns has helped me considerably. I'm not saying knowldge of design patterns is the only thing you need to develop a flexible and robust architecture, but it at least ensures you do not make any egregious mistakes in addressing well-known and frequently occuring problems, it provides a baseline, you obviously need to know the innards of the technology you'd finally be using for development to provide a good architecture but you really can't just go ahead and start typing up your code unless it's a miniscule application you are developing. Keeping all these in mind, I would not suggest this book to everyone, though I would love to, I do recognize the fact that not everyone focuses on the same area, different people do specialize in different areas and I respect others' rights to think completely differently than I do, so I'll suggest this to softwear architects, present/would be/wanna bes, those who want to keep out of that area are better off by keeping away from this book, the only suggestion I have for them is that they should not say that this book is worthless just for the fact that it's not been written for them.
| 
