17 of 17 people found the following review helpful
on August 13, 2002
From all other people's reviews, you have already known this is the classic text on the subject of design patterns. This is indisputable so I don't need to waste time trying to prove it again.
However, I would like to say something to those readers who are totally new to design patterns and C++/Smalltalk -- please do not be intimidated by the seemingly terse, dry and difficult style of this book. Since I myself am new to the world of design patterns, I would like to share with you my own experience and hope you can make a better decision when you pick your design patterns book.
"Design Patterns" is the classic text; its style is academic-oriented, rigorous, and terse. Unlike most popular computer books, you will find reading this book takes a lot of thinking, for each paragraph or even each sentence. Most examples used in this book are adapted from real world systems popular many years ago, so you will likely find you're not familiar with them at all. Moreover, some examples are related to GUI programming, so if you're mainly programming for backend, you will probably feel it's tough to understand some of the examples. Most code example in the book is written in C++ (some in Smalltalk.) If you're a Java programmer and have limited knowledge in C++, it might take you some time to guess what certain C++ syntax means.
These all seem to be negative comment, but my conclusion is to the contrary -- this is the BEST book in the area, and you should read it despite of all the issues I mentioned above. I started my design pattern learning by using a couple of other books, such as "Java Design Patterns: A Tutorial", "Design Patterns Explained: A New Perspective on Object-Oriented Design", and "Applied Java Patterns". I chose these books mainly because they seem to be much easier to understand than "Design Patterns". However, after spending time in these alternative books, I found none of them offers the accuracy and depth as "Design Patterns". Often, after I read a chapter of the "easy" book, I feel I am still kind of lost. I seem to have understood the pattern I just learned, but then I feel it's not quite so. I guess I only learned the pattern in a superficial way, with little depth, and without being part of "big picture." Later, I turned to the classic, "Design Patterns". I forced myself to sit down and try to understand the authors' terse and rigorous writing and their unfamiliar examples. Gradually I found I was getting used to the style and the examples, and I actually started to learn much more from this book than from others. After reading half-way through the book, I felt the rigorous style is actually a big plus for this book, because I can get more accurate and in-depth information.
Therefore, I strongly suggest that you buy and read this book, even if you feel it's difficult to read. Your effort will pay off eventually. Use other books as reference only.
7 of 7 people found the following review helpful
on May 1, 2004
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?"
1 of 1 people found the following review helpful
on July 31, 2003
I came across this classic pretty innocuously. Some colleagues suggested a design patterns study group and from that day I was hooked. This book teaches you more about Object Oriented programming than all the other OO books combined.
Each pattern opens up another facet of Object Oriented programming. Once you are done with all the patterns, and then, done with them again, and then, done with them again you feel the euphoria of having understood something so abstract, but at the same time so tangible and visible around us. Be it Java, C++ or any other OO language, your design ideas and orgranizations become incredibly elegant and simple. This, is something you learn and appreciate only if you have gone through this book. And, here, by "done with them", I mean a thorough study, sample implementations, production implementations and the ability to recognize that pattern with its subtle variations.
The GoF book ( Gang of Four ) is structured as a manual of sorts, and it requires some orderly study. Look up Design Patterns Study Group on Google. The study orders suggested there are worth mulling over. The simple patterns are easy enough to understand ( Factory method and the like ) and the complex ones ( Visitor ) can be digested with the understanding of the basic patterns.
Again, at the end of the book, ( there is so end to this book, though ) you might actually end up mastering OO coding.
Couple of possible criticisms on this book is that you begin to think in patterns for every problem. Which might not be entirely good, and this book doesnt encompass the full world of pure OO patterns ( collecting parameter, for example ). But its still THE book to start with.
It also helps that this book has become a standard of sorts and the terms and jargon presented in this book are highly visible in the OO design and programming world.
Worth a Buy, Worth a dozen reads.
on November 12, 2003
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!
on October 13, 2003
I have heard numerous accounts from programmers of varying experience levels on how this particular book and set of concepts changed the way they approach object-oriented software. Object-oriented software is about object interaction, implementation is trivial in a system where a reasonable framework is set.
Good object-oriented design, it is true, existed before Design Patterns was introduced, but it is the way object-oriented design was given a set of commonly agreed intuitive names of generic object traits that this piece of holy software scripture earned its place in the 5-star-league. By discussing and using agreed concepts, the processes involved with design, implementation and refactoring can be exposed to a much broader audience, because applying these naming conventions in code implies desired functionality. The approachable, yet rigorously thought-out guidelines in this book further makes reviewing code more efficient because comparison against tested design approaches can be utilized, pointing out many common pitfalls.
A word of caution. This work is very inspirational, and junior level programmers might, upon leafing through this book, emerge even too enthusiastic on applying generic design on systems where simpler approaches would be more logical.
on October 5, 2003
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.
on February 13, 2003
I was still a fledgling developer at the time I attempted to first read this book. My initial impression was that it was outdated and dry. But as the months and projects went by, I began to understand the importance of patterns in general and this remarkable text in particular. Indeed, without much experience in the field, one might find this book too theoretical, or even irrelevant to practical work. But one day, you'll find yourself faced with a particularly nasty problem, and all of the sudden a pattern will flash in your mind, and click! The connection is made, and the problem is solved. It was very gratifying for me to experience this feeling over and over again; as I'm sure it would be for any junior developer just getting his feet wet.
Two words of advice come to mind, though: First, please keep in mind that the patterns herein are not the only ones out there; there are many others documented in various other books and articles. Second, be very careful of the Singleton pattern; it is the most overused and abused of the patterns, simply because it is easy to implement. And note that the text says nothing about the destruction of a Singleton, so watch out.
It is my opinion that this book should become mandatory reading for all software developers of all levels, and the patterns within it should be as common a construct as an "if" statement or a "for" loop. Please, do yourself and your profession a favor and read this book.
on December 22, 2002
I've been a C++ programmer for quite a while. Every three years or so, it seems there's some revolutionary text or other that promises huge leaps forward in the art of software design. This book, extreme programming, various modelling languages and techniques, 4GLs, etc etc. I can remember people arguing that everything C++ would be different once it got a standardized string class.
The patterns in this book lie largely within my experience, and none would not be obvious without careful analysis of software requirements. Really, what's new about an Iterator pattern, or an Interpreter, State, Builder, Adapter, or Proxy? In my experience, this is like people raving on about the benefits of hash tables or doubly-linked lists. If you want a mind-opening experience, do something interesting (and hard at first) like writing LISP code to interpret an arbitrary expression using only compiled functions. No, your negative college experiences do not apply.
In conclusion, if you're new to programming, this book does contain useful wisdom that comes from experience, and this is largely hard to come by. As another bit of wisdom: avoid trying to simultaneously apply as many patterns as possible. If you're an experienced programmer, though, you probably already know and can explain everything in this text.
on December 19, 2002
This is an excellent book which teaches more than a few gems of software development and design. Developing to interfaces to be independent of implementation, favouring composition over inheritance, and the art of delegation are but a few.
The design patterns themselves are awesome and they take a while to sink in. I would be surprised if you could read through the book once from cover-to-cover and understand when and where each design pattern could be used. The authors give some good examples, but you really need to USE the design patterns to fully appreciate them. But, bear with it, this is a book worth studying! Study each design pattern, apply them, be enlightened.
One thing that struck me is that many of the patterns are similar and overlapping. They are not as distinct as one might originally think. In fact, it has become clear that the majority of patterns consist of composition and delegation, DELEGATION being the key concept. Understand and learn the art of delegation and you will become a better designer of design patterns. Understand the art of design patterns and you will become a better designer of software.
A truly excellent book that facilitates knowledge transfer of software design best practices. The beauty of this book is that it has probably contributed more to the adoption and spread of the software design pattern paradigm than the actual design patterns themselves. Bravo! We are all better off for it.
on October 20, 2002
This book is a catalog of 23 more or less useful object oriented design patterns in more or less wide spread use. Don't get me wrong, I do like the book's intention of introducing a common vocabulary of solutions to particular engineering problems and it is certainly valuable having these solutions collected and organized in one place. However, I think it is unnecessarily dry and hard to read. The source code examples on the other hand are written in easily understandable C++ with brief mentions of existing implementations or implementation possibilities in different languages. I would have wished for more and more elaborate examples though. The authors often mention the possibility for mixing several patterns to archive their combined strengths, but seldom give code examples demonstrating this - thus leaving the harder problems to the reader. I would have liked less emphasis on the sometimes obscure and outdated 'known uses' section for each pattern - which cites where the pattern has successfully been applied - in exchange for more actual code examples. Sometimes the 'known uses' section reads like an excuse for including that particular pattern, which should be unnecessary, the use should be self evident or the pattern omitted. That said, I still haven't found a use for some of the more esoteric patterns in my everyday designs and application of C++. The book is still a valuable reference, since many patterns (factory, singleton, observer, command) really are in widespread use and you don't want to miss out on their usefulness and seem ignorant in discussions about them ;)