Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) Reviews

• The best way to really learn object-oriented design

  
  By on 1997-03-07
  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
  
  

• Must read, but requires some sophistication

  
  By AXH34TXSUTQK1 on 2000-05-15
  As you probably already realize from the large number of reviews, this book is one of the seminal books on patterns in software development. If you are a professional software developer, you must read this. If you are learning to write good software, this is a book that you will need to take on at some point, but I urge some caution.

  In particular, many of the patterns in this book represent highly distilled wisdom about effective solutions -- distilled so far that, unless you have implemented code that realizes the pattern in question already, you may have trouble absorbing the material. I find that programmers-to-be who dive into this book, often end up talking annoyingly about "applying patterns" without having a real grasp of how these things translate (with some distortion and compromise) into real projects.

  That being said, an excellent way to bridge the gap is to read this book along with "Pattern Hatching : Design Patterns Applied" by John Vlissides. That book is a chatty companion piece for this one -- I found myself understanding how to incorporate patterns into my day-to-day design work much more after reading both books.

  See: Pattern Hatching : Design Patterns Applied [also at Amazon.com]

  Overall, while this book is an extremely important contribution to software developers, it is structured in a way that makes the material difficult to absorb if you aren't approaching it with substantial previous knowledge about developing software. You can start with some of the simpler patterns (Singleton, for example) and work through the harder ones, but only by implementing projects and stumbling upon these yourself will you really feel a flash of recognition as you read them in the book.
  
  

• Now that the hype is over...

  
  By ALIFLQ9OH738B on 2005-01-19
  ... 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.
  
  

• Excellent concept but rather disappointing mistake density

  
  By A1OE1WDO2KTZA on 1999-12-22
  I rate this book 5 stars for the idea and -2 stars for all the confounding little mistakes. Apologize, I don't have too many details because it was one of the few books I borrowed that I actually returned (and to the original owner).

  I went through two of the patterns with full concentration, found mistakes in both and found they really did get in the way. Things were named or referenced in ways that just couldn't be right. I wrote to the authors about a few issues (e.g. on pg 275, Widget should reference DialogDirector, not aggregate it) and the response (Johnson, Vlissedes) was very kind and constructive. But I believe there is significant work remaining. You may think I'm being overly picky here (at issue on pg 275 is an itsy bitsy little shape), but try understanding something completely new when there is one mistake in it. You wonder if you're comprehending wrong.

  I have a hunch that most folks here, pardon my presumption, who are rating high without reservation are really in love with the idea of finding patterns to design (as am I). But I wonder if they've ever really really tried to go through any of the examples at a finer resolution than a bird's eye view. The book does a lot to crystalize the dream of reusable design patterns but not as much as it could to wake us up to realizing it.

  Still it's on my list of things to buy because it's darn thought-provoking. Maybe that's it's highest purpose: to announce, if only by the title, the shocking idea that there could be patterns to design, that programmers might not always have to reinvent the universe with each project. (The idea that they don't is not new, but the *fact* that they don't is making woefully slow progress.)

  The big question I still have is did they pick really good patterns and objectify them with compassion and vision? Are these the very paradigms and clumps of computational power that will be in the toolbox of programmers yet unborn? Dunno. I suspect from the tactical gaffs that strategic corrections are in order.

  Maybe 3 stars isn't harsh enough but it's certainly a pioneering book. I believe one significantly better will come out in the next decade. It would be nice (somehow in my rosy view of the world) if it were by some of the same guys...
  
  

• Not for the faint-hearted, but a must read.

  
  By on 2000-02-11
  Obviously, this book is *the* most recognized reference work on software-related Design Patterns, and as such cannot be ignored. If you want to know about patterns, here is where to start.

  The main asset of this book is in its trustworthiness and credibility - not such an easy thing to come by in computer books these days. I went through many if not most of the C++ examples in detail, and did not find a case where it didn't hold up, at least to the extent where it clarified what the point of the pattern was. The UML diagrams are also extremely helpful.

  Be forewarned, however; this is not light reading. The examples are based on heavy-duty design tasks your average programmer doesn't face, like language-parsing, toolkit creation, compiler writing, and the like. It makes one wonder how applicable many of the patterns are to less complex programming tasks.

  Also, most of the examples are in C++, so you really have to understand the syntax of C++ before you can get much value out of this book. Another drawback is that many of the examples are abridged, so at times you have to kind of extrapolate on what some of the code *would* look like in order to understand the examples. The chapter on Interpreter in particular was a tough nut to crack due to this. I actually would have liked to have seen *more* explanatory text associated with the code itself.

  For all that, many of the patterns are pretty staightforward. The trick is to nail down that you "get it" for each pattern. One technique I found enormously helpful in accomplishing this was to write a summary of the pattern after reading a chapter - right in the book, so it can referenced later (there's often an entire blank page opposite the beginning of each chapter you can use for this). You may find yourself delving back into the chapter to confirm your understanding.

  Overall, a challenging but ultimately rewarding read for anyone who wants to understand what design patterns are all about.
  
  

• The classic, and still the best
  By AZGX39ZNBE7GM on 2002-08-14
  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.
  
  

• Possibly the most practical textbook I've read
  By A1CRF299KXQ38G on 2000-10-31
  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."
  
  

• Too bad I can not give 10 stars
  By A3EOEK02685D7H on 2001-02-07
  This is absolutely one of the best books on OO design. I am a System Archtect and I can't image how my design (and Java) would look like without applying the concepts and patterns described in this book. This book, IMHO, plays a much more important role and should enjoy a much higher reputation than the UML series written by the 3 Amigos.

  This book is definitely not for those who still do not understand the virtue of the concepts presented in the book. This book is not for programmer level either(although they can still greatly benefit from the book to enter the next level). The examples in the book are in C++ but the patterns it describes is language independent. Those who really know Java(not just reading sth like Teach Yourself Java in XX days,weekends,in a nutshells, etc) should tell immediately that lots of patterns are already applied in Java, especially in J2EE. Knowing the patterns in the books not only make your design step up to the next level, but now also a MUST if you want to pass the perfessional certificate exam like SCEA. I have to say no one can claim they know OO design without knowing the concepts and patterns described in this book.

  This is one of those few books in computer world that will receive more and more recognization as time gose by. In three years no one will even mention 90% of those books currently getting five stars, but this one, I have to say, will be in top in foreseeable future and much longer.

  I totally agree that this book is a little bit hard to read. Please think it this way, anything you can learn in 10 minutes is useless and of little market value because anybody can do the same. Those who grasp the essence missed by the majority are distinguished and of high value....
  
  

• a must read, but a very tough read.
  By A3G8QY0MC6CUPL on 1998-07-03
  The authors define design patterns as: descriptions of communicating objects and classes that are customised to solve a general design problem in a particular context. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Easy to wrap your mind around, eh? Design Pattern people are in love with the power of abstraction and generality. You might even say they prefer to impress rather than inform. However, somehow you are going to have to learn this stuff, even if only to get into the heads of the guys who designed the AWT. Try starting with the code samples in the Design Patterns book. You have to read this book at least twice before it begins to make any sense. However, if you want to call yourself a programmer you MUST understand this book. I hope somebody writes a version of this book for Java programmers. It is written from the perspective of C++ and Smalltalk. This is a book where the you want the hardcover version. You go back to it again and again.
  
  
• The original and definitive work on OO design patterns
  By A2WFP80NYOXD19 on 2001-05-16
  Design Patterns, referred to warmly as the "Gang of Four" book by it's fans, is the book that introduced me to the world of design patterns. After reading this book, you'll immediately see patterns from it everywhere - many classes you use every day will suddenly all fit together in a pattern.

  Besides being a tool for writing good maintainable code, patterns are a crucial tool for communication among developers. Knowing even a half-dozen of the basic patterns will facilitate communication among team members immensely. For instance, you may be having a whiteboard design session with another developer or two, explaining some particular design you have in your head. Instead of having to detail 3 or 4 or more classes and how they would interact, you could simply say that you are thinking of using the Factory pattern here, and the Decorator pattern over there, and the others will know exactly what you are thinking.

  The patterns are grouped into three groups: Creational, Structual, and Behavioral patterns. Each pattern is considered in turn, each having sections detailing the intent of the pattern, the motivation for using it, the consequences (both good and bad) of its application, collaboration among the objects involved, and examples.

  The examples are mostly in C++ with a small dose of Smalltalk, but the patterns are equally applicable to any object-oriented language, Java in particular. Some of the patterns can be implemented even more simply and cleanly in Java, as a result of language features such as dynamic class loading, among others.

  This book is well-written, and it's a quality book well worth owning. It even has two nice ribbon bookmarks attached to the binding which makes to book even more practical as well as handsome.
  
  

• Useful, but not all that useful.
  By on 2002-12-22
  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.
  
  

• It has no competitor doesn't mean it is great
  By on 2001-03-29
  If there is one single book that covers a wonderful topic and is absolutely unreadable, this is the one. I saw so many favourable reviews of this book that I almost started thinking that there was something wrong with me. Then I met some guys, who like me, attempted to read the book umpteen number of times and then gave up.

  This is one of those 'classics'. You know what a classic is: books that everybody praises but nobody reads. Trust me, most of the people singing praises of this book here never read more than 5 pages. They were not able to.

  Still this book continues to sell. Why ? Because there is no alternative. It adorns millions of bookshelves, remaining one of the most rarely read software books.
  
  

• Great use of online information, but...
  By on 1999-04-22
  I own the original book and love it, but I was a bit surprised when I bought the CD and saw that the price only covers a single user - the normal price does not allow you to the put the CD on a web server for a group of programmers. Given the way software works, maybe I shouldn't have been surprised, but come on, if you buy a CD of WEB PAGES, shouldn't it be made clear up front that you're not supposed to put it on a WEB SERVER?! Caveat emptor...
  
  
• An approach to this software classic
  By A3IGFG6XD49C1R on 2006-09-06
  "Design Patterns" (GoF = Gang of Four) is a signicant and, in many ways, a difficult work for the modern reader (me) to digest. The material in this book is highly self-referential: to understand a particular design pattern, it is important to be familiar with many similar, if not all, design patterns.
  
  I would like to offer a suggestion about an approach that worked well for me. As an introduction to the patterns field, I first read "Head First Design Patterns", which offers a highly competent but light-hearted presentation of the same patterns covered by GoF. The Head First book gave me a thorough overview of the patterns landscape, as well as gently drilling me on pattern application. The Head First book goes out of its way to provoke the thinking reader, while being the most entertaining computer science text that I have ever read.
  
  With this introduction, I found "Design Patterns" to be a much more accessible and friendlier work.
  
  
• the reference on the topic
  By A2J1PPW52AT2GK on 2002-10-20
  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 ;)
  
  
• An excellent complement to the book of the same name.
  By A2A1JRDJP616WD on 1998-07-09
  This CD should not be considered a replacement for the book, at least as long as you are like me and like the portability of a book, it's ability to record notes, etc.

  What John Vlissides and the folks at AWL have done very well is re-shaping the book to electronic form. This is not just a duplication of the book, but a genuine adaptation of the content to a different medium, in this case HTML. Perhaps most valuable for me is the ability to pop this in and do a full-text search. I still use the paper book, though.

  It would have rated 5 stars but for one thing: the inability to record notes within the medium. That's not the fault of the publisher or anyone--it's a difficult technical problem that hopefully someone will solve.

  I would heartily recommend this to consultants or anybody who doesn't necessarily have a "home base" because these are much easier to lug through airports than the hardcover GoF book. :-)
  
  

• Not for "Programmers"
  By A1CAGNJ8JTWHIO on 2001-06-21
  This book is for Software Designers or Architects; if you've happy being a code monkey don't bother buying it.

  Some of the examples were in Smalltalk. I had never /seen/ a line of Smalltalk code before, and did not have difficulties following the Smalltalk examples. I am familiar with C++ though.

  The book is heavy; I not only read it not only once but twice. It will be hard to appreciate and understand the patterns without using them. Like a decent math book, it cannot instantly plant the knowledge in your head; it takes some practice. If you do not feel you would be (or would have been) capable of teaching yourself calculus, then there's no good reason to believe you will be able to teach yourself design patterns (though there is more material to cover in calculus, it's about the same difficulty and level of abstractness as design patterns).

  The reason I believe some people have disliked the book is for one of two reasons; they had insufficient knowledge of object oriented languages (Java complainers), or didn't understand that design patterns are extremely abstract concepts. You should know that C++ doesn't have first class functions and that Java only has single inheritance. Fully implementing patterns in Java will be tedious if support is not already built-in (i.e. Java's Listeners are it's implementation of the observer pattern). With C++'s MI and macros you can build some template base classes to implement "pattern plumbing"; like the ATL for COM. I will also concede that the book is not perfect, but it is the best one available on the subject of design patterns. In 7 years no one has done a better job.

  One complaint I have is that the language is so plain it hurts. I now greatly appreciate the dry wit of Charles Pretzold and the zanity of Andre LaMonthe.

  P.S. The diagrams are not in UML. Since UML requires a book in it's own right, for simplicity sake they didn't use it.

  1999 BS Computer Science & BS Mathematics from Lawrence Technological University, "Theory and Practice"

  Magmai Kai Holmlor
  
  

• You've written a million lines of code, Now... do it better!
  By A1KCW7P6QWUUFB on 2001-09-27
  ...

  After years of writing code of all kinds,

  Fun Video games as a kid,
  Compilers for the heck of it,
  Graphics programs for the love of art,
  Interesting AI programs because I am a CS guy,
  Boring Database Applications because I have to pay bills,
  Nifty n-tiered web apps because the World went crazy..,

  I found a programming book that could still teach me something.

  After books from Knuth, Djikstra, The Aho Gang and the like, here is a book which goes straight to the point.

  The book summarizes a basic set of Software Design Patterns, which have been found over and over in all the software we create.
  Design Patterns is the perfect answer to all you OOP questions, Its an approach to sofware design as well as reuse.

  If you are an artist, you would appreciate Design patterns better. The masters of the Renaissance began to see the world in terms of basic geometric forms..Spheres, Cubes, Cones and cylinders..this helped them in analysing an object..(any object, from the Human body to the Mountains and rivers.). Once they analysed any thing into its basic forms it was just a matter of detail. So, if you practice how to draw these basic shapes from different angles, and lighting,etc., and you learn how to analyse any thing into basic shapes, you have become a master.

  The authors categorize all different software pieces into Creational, Structural and Behavioural patterns. Providing several possible patterns in each of these categories. A software designer, when confronted with a design problem, based on the needs, can pick a pattern from this catalogue and then fill in the details.

  Well written, with UML diagrams too.

  Caution: If you are new to programming, come back to this book a bit later.
  
  

• Must-read for Object Oriented Programmers
  By AV43VPYZNJ7ZB on 2000-11-25
  This book is a very interesting discussion of certain Object Oriented structures that continually reappear in solutions to computer science problems. This book outlines each pattern in great detail, giving its definition, use, and examples of each. The detail may be a bit much, causing the book to drag a bit, but it is invaluable later on when using it as a reference. The key benefits of design patterns are that they provide you with a common OO vocabulary for discussing these issues with other developers, and that they allow you to reuse certain core elements of an application, not having to solve a particular problem again and again. The book is an essential read for an intermediate to advanced OO developer. I hesitate to give it 5 stars because I think the book would have benefited from a more concrete sample application that brought in the patterns and showed the ways in which they communicate with each other, with sample code as opposed to diagrams. Even so, this book is great.
  
  
• Get this book even if you are a Java Architect
  By on 2001-08-25
  As far as I am aware this is the only book available on the application of design patterns specifically for Object design and is useful for Java architects as well as for its intended audience, C++ programmers. If you are having difficulty with this book then getting yourself a copy of Christoper Alexander's "A Pattern Language" is a good place to start looking at the concept of patterns and their application to Architectural models in the physical world. While many software designers and webdevelopers rave about "A Pattern Language" the worlds first book on Design "Permaculture a Designers manual" by Bill Mollison is even more universal in scope than "A Pattern Language". This is due to the fact that "Permaculture a Designers Manual" draws its design methods directly from observation of how natural systems work and from that, building integrated systems based on the concepts of Physics, Ecology, Hydrology etctera. The concept of Permaculture is the inspiration behind the concept of the worlds most innovative science thinktank "The Santa Fe institute", permaculture as a concept predates the "The Santa Fe institute" concept by over a decade. The chapters in "Permaculture a Designers manual" that cover, "concepts and themes of design", "methods of design" and a "pattern understanding" are worth their weight in gold. One design principle that stands out is the concept of one principle in particular which states that each single element of a design must perform at least two, but preferably more functions. Such designs based on this principle alone can give your object, site or application an extremely huge bang for you buck. If you are a designer and you wish to learn the "triggers" that facilitate good design then there are three books that you must have, "Design Patterns", "A Pattern Language" and "Permaculture a Designers Manual". Whether you are new to design or a professional in this field get these three books, read, "Permaculture a Designers Manual" first to get an overview of how to design models that are universal (ie; adaptable from one discipline to another, for example the principle of edge effects in ecology, used to build objects that foster community growth in a specific Online portal). read "A Pattern Language" second to get an overview of the psychological principles behind Architecture that makes sense to the user and enables them instead of disempowering them (For example the navigational structure for finding the subjects of this book gives an example on how to build a navigation structure for websites or software that makes it easy for the user to navigate to the exact subject that the user wants in just one click) After you have read these two books then read "Design Patterns" to find out how to design objects well and use it also as inspiration for designing Java Architecture. Read these books in the following order and you will have what many programmers beleive is the best selfpaced tutorial on design that you could possibly get. Unfortunatly at present there is no course that has these three all time design classics as the basis of its curriculum, only those who are aware of what the best designers use as their reference material, buy these books, as a result many lecturers are doing thier students a huge disservice. Newsflash; "Permaculture, a designers manual" is no longer for sale on Yahoo as of September of 2001, this book can only be obtained over the web through its publishers "Tagari.com.au".
  
  
• never a surprise to me
  By A3HBME3AO6OSOY on 2003-08-01
  It is too bad other experienced authors like Stephen Prata, Stephen Kochan or Ivor Horton didn't write this book. These authors write books that can be easily assimilated. The book covers a worthy subject and has received aclaim because:
  there is honor amongst thieves and elistists and their groupies
  people travel in cadres
  Booch, Fowler and Larman write horribly and people froth at the mouth. A professor once said he read Booch's 1992 book 3 times and asked himself what he learned and he decided->nothing! My thoughts exactly!

  Before I read the book, I heard that it uses words/concepts before properly defining them. This is true. The book should be rewritten and the authors horsewhipped. The authors discuss examples they obviously are very familiar with. I spend most of my time rewriting the book on the fly. Books are written to save time and this book doesn't. Much of the dialog is padded with useless run-on statements. Good grief, somebody write a book about operating a toilet or preparing breakfast cereal.
  If you like this book, you are unable to think for yourself.
  Another review suggested that the authors didn't know what they were talking about. Hard to say...some people should not write books. I remember once writing several pages and looking back realized, nobody will know what in the bell I am talking about. Maybe I didn't!

  In Booch's more recent book, he uses the black diamond. I emailed Booch and asked where he defines the black diamond. A month later back comes an email "chapter 16"

  Booch and Larman are experts at padding. I read 50 pages of the Larman UML book and asked myself what I learned...NOTHING!

  Another horribly useless book some people actually liked was a book on OO Multithreading by Hughes and Hughes. What a lie!

  Wake up people and learn to think for your selves rather than following some famous person.
  
  

• Eye-opening, and still applies
  By on 2001-12-15
  This book helps those less-experienced with OO design to see the true power of OOD, most notably polymorphism and decoupling. I thought I understood before, but I now have a much better understanding of the usefulness of interfaces and upcasting, and why composition is often a better solution than implementation inheritance.

  I chose to read this book while I was learning Java. For me, it worked well to read one pattern per day and try to get the most out of it. Reading several patterns back to back will likely get exhausting for most. The presentation of the book is very conceptual and academic. Even ten pages of reading may fill your head for a while. So be warned that you will not likely knock this one out in a couple sittings!

  This book also provides the reader an education on the importance of patterns in general. Although the current world of web services and stateless objects will deemphasize the usefulness of some of these "classic" patterns, the IDEAS layed out in this book (interfaces, layers of indirection, etc.) will hopefully help all of us discover next generation of patterns.

  My only wish is that they would come out with a new edition of this book that:

  a) Documents code in Java (those not knowing C++/Smalltalk may struggle)

  b) Chooses less technical examples (e.g., a pattern demonstrated on a payroll application instead of a compiler subsystem)

  c) Updates to the current version of UML (although the current modeled documentation is not bad)

  d) Provides new patterns that help people with wireless, Internet, web services, stateless objects, etc.

  e) Changes the tone to be a little less academic (this is really just a nitpick)

  All in all, this was a very useful book and was worth the brain strain it required to read and grasp it's concepts. It has aged well despite being written prior to the WWW becoming a household word.
  
  

• horrible book. Very hard to read and not very explanatory.
  By A2MNKF9FXP9NJ1 on 2004-12-02
  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.
  
  
• A core book for any OO programmer.
  By A1E4REA11S1126 on 2000-06-15
  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.
  
  

• CD Edition is Awesome!!
  By A67CR6YCB462C on 2000-09-30
  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!!
  
  

• Studying Design Patterns vs. Improving Software Development
  By A2LFP53IUVG29C on 2005-10-01
  It's hard to imagine how a software developer in 2005 could function without ready access to this 1995 classic. Without this book how could anyone
  * Explain why the Factory Method pattern (page 107) is a special case of the Template Method (page 325) or why it isn't.
  * Prove that Java's DriverManager.getConnection(...) method illustrates the Abstract Factory Method design pattern (page 87) rather than the Factory design pattern.
  * Think of any practical example of the Visitor pattern (page 331).
  * Agree on whether or not a given piece of software actually illustrates a specific one of the 23 patterns identified in this book.
  
  Like the Guinness Book of World Records settles arguments between drinkers this book is the final authoritative arbiter when software developers argue about design patterns. This book is also useful for learning how to use design patterns to design and write better code.
  
  It is a testament to the importance of this book that in the ten years since it was published the design patterns community has not really agreed on any additional patterns beyond the 23 defined here--although many more have certainly been proposed. Even more significantly, few have had the courage to suggest that some of the 23 patterns defined here might be of little practical value. Most design pattern book authors since treat these exact same patterns. I suspect their publishers insist on it because that's what the buying public seems to want. As a result it is certainly fair to say that once you buy this book you don't really need to buy any more books on the subject.
  
  In fact, one might argue that this book is one of the few design patterns book you can buy that is 100% focused on helping developers write better code. Other books that dare to introduce valuable new ideas on design patterns typically include an explicit acknowledgement that the ideas that can't be traced back to the Gang of Four. Any time spent defining yourself in terms of the Gang of Four is time that is not being spent advancing the field itself or helping developers.
  
  Another indication of the importance of this book is that fact that other design pattern authors often quote it directly, particularly the short definitions of the design patterns. This might suggest that other authors find it difficult to understand some of the 23 patterns well enough to be able to clearly and confidently explain them in their own words. Whatever the actual reason, it certainly indicates that if you want to buy a book on design patterns, this is the book to buy.
  
  I wish the authors of this book would publish an official statement giving their disciples explicit permission to move forward with design patterns, improving and adapting them, adding new ones and letting those that haven't stood the test of time gracefully fade away. As it is, the study of design patterns is in danger of becoming a study of this book rather than a study of how to actually write better code using patterns.
  
  I'll close with a significant and apparently overlooked line from the preface of this book:
  
  "We don't consider this collection of design patterns complete and static; it's more a recording of our current thoughts on design."
  
  
• Still the best
  By A3TSRCI6MK8UL8 on 2005-11-24
  Over ten years ago I found myself at a seminar given by Ralph Johnson. My employers were keen to send us on a course and I had literally picked one at random out of a magazine because the title sounded good (same title as book).
  
  I found the seminar confusing and stuggled to grasp what Ralph was talking about. What did he mean by a singleton? As an 80's computer science graduate I had had very little real teaching of OO other than what I had learned off my own back and I thought I understood it well enough. Because of this I quickly wrote off what Ralph was describing as 'academic nonsense' and even said this to my workmates who were as out of their depth as I was.
  
  But..I was the only one of us who went along to the seminar that actually bothered to read the book. In hindsight I can see this as _the_ major turning point in my career as a programmer and developer of software. This book is for everyone who is interested in OO design but for some developers this book will be like a 1000 watt lightbulb switching on inside your head.
  
  
• Required Reading. Absolutely Fantastic!
  By A1ZCC83SBTTSVE on 1999-11-11
  Design Patterns is required reading for all object-oriented designers, developers, and architects who want to improve and streamline their design skills. This book will open your eyes and teach you how to utilize widely accepted and standardized design patterns to implement efficient solutions for frequently encountered design challenges. You'll immediately recognize multiple instances within your own projects in which design patterns would have improved efficiency and reuse within the architecture.

  The authors take a very methodical approach to describe every aspect of each design pattern including applicability, structure, collaborations, and consequences to name just a few. The book is extremely well organized making it easy to refer to the catalog for a refresher on various patterns.

  One of the best OO books I've read.
  
  

• A good <>
  By A3IDK14T1LZAGN on 2000-12-30
  An interesting book for thinkers who are desinging software. Not really for brute force, keyboard bangers. Start using the terms in the book and you lose a few of these kinds of friends. This reference is quite useful, because patterns exsist in designing and programming. Most of the time they are not documented. This work shows how these design patterns interact with each other and how to use them together. There might be some other new or different patterns which resemble or are derived from the foundation laid here. Personally it has help me think and design faster; after a first reading, I found it easier to read through, understand and remember source code written by other programmers. What I can say is that the terminology will sound alien to anyone who has not read the book, but the patterns will be easily recognized by anyone into serious reusable OOP. The botton line is that this book is an asset for any designer, programmer; it helps you to think. You have to read it.
  
  
• Good concept, good material, hard to read
  By A132FCKZZYSHBY on 2000-12-27
  i think this was the first formal book on software patterns. It's certainly the most popular - every senior object guy i know has this. It has some good material in it, and if you haven't at least memorized the names of the patterns in this book, you might get left out of a few conversations

  The one criticism i have is that the authors are clearly not professional writers or teachers. This book is BORING. Really, really boring. It's still a good thing to own, but you ain't gonna read this cover to cover in one sitting and, many times, you'll probably have to steel up your will and tell yourself it's good for you before you crack open the book. It's a good book, but it was written by professional programmers and it shows

  Of course, i don't know anyone who took the concepts in this book and wrote something easier to read, so you probably should buy this one
  
  

• Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series)
• Emergent Design: The Evolutionary Nature of Professional Software Development (Net Objectives Product Development Series)
• Implementation Patterns (Addison-Wesley Signature Series)

• Code Complete: A Practical Handbook of Software Construction
• Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)
• Head First Design Patterns
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition) (Addison-Wesley Professional Computing Series)
• The Pragmatic Programmer: From Journeyman to Master