Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming Books Media Book Reviews IT Technology

Design Patterns 314

BShive writes "Design Patterns is considered a classic for anyone in software development. The beginning third of the book is a solid introduction to patterns, while the last two thirds of the book is devoted to the patterns themselves. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about. The frequency of hearing about this text in discussions piqued my interest enough to buy it for myself. If you are interested in design patterns and are looking to use them, then this should be one of the books on your shelf." Read on for more.
Design Patterns
author Erich Gamma, et al
pages 395
publisher Addison-Wesley
rating 8
reviewer Ben Shive
ISBN 0201633612
summary Design Patterns is considered a classic for anyone in software development. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about.


I found the entire introductory section excellent, and a good read. It covers what design patterns are and explains how they are documented and categorized. Advice on where and how to employ design patterns to achieve reusable and flexible software is also covered to give you an expectation of what you can get out of the rest of the book. The What, Why, and How are covered nicely. Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.
Object Modeling Technique (OMT) notation is also introduced to explain the diagrams associated with the patterns and examples. If you have used UML, the diagrams and notations will be familiar to you since UML is influenced by OMT. Jim Rumbaugh, the creator of OMT, collaborated with Grady Booch to create the first version of UML.

As the author notes, having a solid knowledge of OOP is critical to being able to understand and use the information presented. If you don't fully understand OOP, pick up an introductory text first. An Introduction to Object-Oriented Programming by Timothy A. Budd or any similar book will get you up to speed. However, you will get the most out of Design Patterns with hands-on OOP experience.

Case Study

This chapter presents a case study in designing a WYSIWYG document editor to demonstrate how design patterns can be applied. Most of the examples in the book involve the user interface and I would have liked to see less emphasis on UI models. However, it still gives the reader insight into real applications of patterns. Not only do the authors point out how the pattern applies to each case, but they also present the problems associated with the application. The case study is not intended to set up a perfect example of pattern usage, but to explore it. The reader could go further with the design presented and think about how to solve the flaws pointed out along with the ones that have not been discussed. I liked the fact that they do not attempt to state that there is only one way to solve the problems presented, or that their solutions are even the best way. Too many authors fall into this trap.

Presenting: The Patterns

The three chapters on patterns make up the bulk of the book. The patterns are separated out into the three chapters by type: Creational, Structural, and Behavioral. Each chapter begins with an overview of what the patterns of the type can be used for, and how the chapter deals with the patterns as a group. At the end of each chapter there is a discussion section that summarizes the patterns, along with guidance on how to select the right one from the chapter.

Each pattern description contains a number of sections: Intent, Also Known As, Motivation, Applicability, Structure (in OMT), Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The breakdown makes it easy to determine if, why, and how you should use the pattern. The authors are justifiably concerned about using the wrong pattern for a given situation. The code snippets are also easy to work through as long as you know an OOP language. C++ is commonly used, with the occasional bit of Smalltalk code.

The three chapters that detail each pattern would be difficult to read right through. However, the opening and closing section of each chapter has valuable information and is worth reading and subsequently referring to some of the patterns discussed. I got the most out of these chapters by picking patterns that might apply to current projects I was working with and then exploring one in depth, branching over into other patterns in a non-linear fashion.


The closing chapter is relatively short, but makes some important points. The authors discuss what to expect from design patterns, some history and other references/influences. Re-factoring is discussed and how patterns will help mitigate this unavoidable process as the software evolves. Other benefits are also brought up briefly. The book closes with an invitation to give the authors feedback and to find patterns that you use. The best designs will use many design patterns that dovetail and intertwine to produce a greater whole.

Book Extras

The whole book has a quality feel to it that is missing from many current texts that cost nearly twice as much. Inside the front cover there is a quick reference to all of the patterns contained in the book with a brief description and page number. The back cover also contains a quick reference for diagram notation and the relationships between the design patters. This is all topped off by two bookmark ribbons attached to the spine.

The Age Issue

Design Patterns was originally published in 1995, and the book mentions that the patterns it contains are little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change. Despite this, since the material is not entirely dependent on a particular language or program it holds up quite well. The examples referred to for each pattern are older software that many will not recognize. An updated version would be nice, but being old does not condemn this book to being useless.


This is an excellent book even if it is beginning to show its age. The fact that it's still very useful is testimony to the quality of the material. A few readers might find the reading to be a bit dry, but the straightforward style was refreshing compared to some other texts. The authors stay focused on the topic and condense it appropriately without going off onto long tangents. Once I've followed through with applying some patterns to projects it might garner an even higher rating. Just from reading about some of the patterns, I could see how they could have applied to previous projects I've worked on, both large and small. The book was certainly a worthwhile investment. If a second version of this book ever comes out, I'd be sure to pick it up as well.


1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion

A. Glossary
B. Guide to Notation
C. Foundation Classes

You can purchase Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Design Patterns

Comments Filter:
  • Is this book worthy of my money or is it antiquated piece of shit? The author of this review didn't include any sort of this question.

    I have only limited funds, and I cant afford something that wont help me. So... all those who bought it, is it WORTH IT?

    • by Anonymous Coward on Tuesday November 05, 2002 @11:39AM (#4599570)
      Get it if you can afford it. If not, try to find a second hand copy. Failing that there is plenty of resources on patterns on the net:

      Bruce Eckel has one in development available here:

      There are other places too:
      http://www.csc.calpoly.edu/~dbutler/tutorial s/wint er96/patterns/

      See what Google brings up for you.

    • by Vengeance ( 46019 ) on Tuesday November 05, 2002 @11:40AM (#4599574)
      Damn straight it's worth it.

      As a developer, this book helps you to codify some concepts you've already got in your head, so you can latch onto them and understand them better. Patterns are applicable at every level, from little 20 and 50 line modules up to arbitrarily large systems. Get this book, or one based upon it that uses the language of your preference.
    • by johnbr ( 559529 ) <johnbr@gmail.com> on Tuesday November 05, 2002 @11:42AM (#4599586) Homepage
      Design Patterns is an extremely valuable reference book. It uses C++ examples, but in almost all cases these can be translated into Java (which is the only other language I use regularly right now).

      It suffers from an overdependence on GUI-based descriptions, which were difficult for me to absorb, given my back-end system focus. However, every few weeks or months something will fall into place and I'll suddenly get the usage of one of the patterns that I didn't understand before.

      Patterns are a great "show off" tool - useful to intimidate those who haven't learned about them yet. Since you'll be on the intimidatee side until you read it, it is good to have a copy for that reason as well.

      Some of the patterns are easy to understand and easy to use - Singleton and Observer. Others take more time before you "get it", and many you may never learn, nor need to.

      But all in all, I think you'll feel smarter for having read it (even if you only "get" pieces of it), and it will probably help your architectural sophistication, and might even present a handy solution to a frustrating design problem.

    • Is this book worthy of my money or is it antiquated piece of shit? The author of this review didn't include any sort of this question.

      That's kind of subjective, one man's 'must have' is another man's 'antiquated piece of shit', so it's always a tricky proposition to make such a sweeping generalisation in a review.

      On the other hand, you should be able to get a flavour of the book from the review and decide if it's something you *might* be interestd in. Then you spend and hour or two in your local bookstore (remember them?) reading and deciding for yourself - which, having never come across the book before and having had my interest roused, is what I'll probably end up doing.
    • by Anonymous Coward
      This is the most inspirational book I have ever read for OO programming. There is no competition. When you read this, you will understand how to programm OO well. In addition, much of Java's libraries are based on patterns, so I say this is a must-read for anyone who wants to learn how to write quality Java code and also understand the Java libraries. The same probably goes for C# since that is Java in sheep's clothing. ;)

      If you like this book, I also recommend trying to find the (free!) whitepapers from Taligent about object-oriented frameworks. They may be hard to find since Taligent is long gone, but I am sure there is a copy on the net somewhere. They did go off on tangents at times, but they are still worth reading. (I believe some of the people who wrote this book were also on Taligent's research team.)

      I used both works quite a bit in my undergrad thesis [tripod.com]. Though without this book's inspiration, the thesis would have likely not come to be.

    • It may be the first and oldest (software) pattern book around, but it still is the very best I've read. Consider this. The book introduces 23 patterns. In the ten years elapsed since its appearance, perhaps half a dozen more patterns have been formulated that can hold their own beside them. Others are derivative, have a very specific application domain, or are about something entirely different altogether (from XML patterns through organisational patterns to anti-patterns).

      If you'd write the book today, you would probably use different programming languages but really, the concepts may be complex but the examples aren't. If you are proficient in one or two modern OO languages I doubt you'll have a hard time deciphering them.

      Treat yourself. Buy the book. Keep it in your bag and next to your bed. It will stretch your mind, clear up your thinking, and give you a new vocabulary.

      - Peter
    • antiquated piece of shit

      The book is about design patterns. How can it be antiquated? Unless you're still programming in BASIC...

    • The single sentence in the middle of page 18 alone is worth you mony.
    • by johnlcallaway ( 165670 ) on Tuesday November 05, 2002 @03:09PM (#4600868)
      Is it worth it?? Can't say, never read it. But,as an antiquated piece of shit myself that has seen every TNBT (the next big thing) come down the road, it probably was outdated 2 minutes after it hit the news stands, replaced by TNBT.

      But, as an antiquated piece of shit who has bought dozens of other TNBT books, it might be worth it. We used to use things called algorithms, and had books written by the thousands with them. I still have a C book on my shelf at work that I reference from time to time because of code segments it has. A good book outlasts TNBT, since they basically all say the same crap. My test is to try and decide if it will make a good reference book, something that will be used every day and can make me an even better haxor than I are now (yes, I meant the poor grammer).

      My advice is to get off your lazy geek butt and get thee to a real bookstore, not one of those Internet things. That you can do for free (well, I think you still can, there might be copyright issues). Pick it up and actually read portons of it. Buy it online if you can save a few bucks, or buy it right there if it is so good you can't live without it.

      But, for geeks sake man (woman??), make up your own friggen' mind. Make a decision. Stand up for yourself. Don't follow the rest of TNBT sheep. Or go buy the damn thing because they said so, and continue to be an Windows NT programmer. (whoopss..did I say that??)
    • so... anyone other than me thinking "damn, he should have put that amazon.com link in via his account for referral points" ... lol. probably make enough dough to grab a book or two for xmas :)

      (though he'd probably get a lot of flak from ppl for making use of it, even though it is a legitimate referral. :P)

    • Is this book worthy of my money or is it antiquated piece of shit? The author of this review didn't include any sort of this question.

      From the article:

      The fact that it's still very useful is testimony to the quality of the material.

      That would appear to answer your question.

  • by StefMeister ( 219044 ) on Tuesday November 05, 2002 @11:34AM (#4599539)
    For a second there I thought it said designing patents. I guess that's what happens when you spend more time reading /. than doing your actual programming work. :)

  • by Anonymous Coward on Tuesday November 05, 2002 @11:35AM (#4599543)
    This book IS the definitive word on the use of patterns, I have used it and will vouch for it.

    However, for all the knowledge it contains it has a price tag to match. If you can get it used and cheap, do so.

  • by CatWrangler ( 622292 ) on Tuesday November 05, 2002 @11:39AM (#4599566) Journal
    I have never seen a code monkey in a well designed patterned outfit. I wonder if this book will help at all.
  • history lessons.. (Score:5, Insightful)

    by TechnoVooDooDaddy ( 470187 ) on Tuesday November 05, 2002 @11:39AM (#4599567) Homepage
    hehe design patterns remind me of the quote "Those who do not learn from history are doomed to repeat it." or something like that...

    if a problem has been solved, and well thought through, the pattern published and peer-reviewed, it probably will hold up for a good long while.
  • by GeekLife.com ( 84577 ) on Tuesday November 05, 2002 @11:39AM (#4599571) Homepage
    Can we get a review of this site, slashdot.org I've heard so much about?

    Sorry, I'd just thought everyone had heard about Design Patterns long ago. Seems a bit like publishing a book review on the KJV Bible or something.
    • Considering that the book uses pieces that are over 7 years old in a world where technology changes every few months, this review was useful to me - it told me that the information was still useful, valid, and actually might help my programming skills.

      So no, I don't believe it was obvious at all - considering that I hadn't even heard of the book until today. (Yes, let the flames commence - I must be a bad, awful programmer because I haven't read some book.)
      • This was one of the required texts for my intro to programming class and even though I've given up programming its one of two books I still find useful. The other being Introduction to Algorithms which I use as a doorjamb.
        • door*jamb [dictionary.com]
          Either of the two vertical pieces framing a doorway and supporting the lintel. Also called a doorpost

          Maybe you should have continued programming, you might have then been able to afford a 2x4 for your doorjamb. Or you could have possibly continued on in school and realized that a doorjamb and a door jam are not the same thing at all.

    • I guess it's a repositioning of "Slashdot: News for Nerds" to "Slashdot: Stuff for People."

      I'm just glad they have their target market so well defined.
  • by ashultz ( 141393 ) on Tuesday November 05, 2002 @11:42AM (#4599588)
    This book is pretty great. It's also pretty dangerous, I've heard of idiots who rate the quality of any potential design by how many patterns it has in it.

    Design patterns is important for every OO programmer to read, understand, and hopefully transcend.
    • I've heard of idiots who rate the quality of any potential design by how many patterns it has in it.

      Actually, a lot of the patterns overlap:

      The Singleton is a subset of Factory, and an Abstract Factory is a subset of Factory.

      Facades are Composites of interfaces.

      An Adapter is a type of Facade.

      (ad nauseaum...)

    • High pattern density shows that the engineer anctualy sat down and thought about design. Most /. kiddies are apt to sit down and start banging code without any design though at all.

      A system showing high density will, by defenition, be better designed that one without.
      • But density isn't mass. You make a design worse, not better, by adding more patterns than are needed to cover the volume of the problem.

        The ideal design will do everything that needs to be done in a principled way using a pattern (either from the book or elsewhere), and nothing that doesn't need to be done.

        Furthermore, you have to make sure that the right patterns are being used. Each pattern is good for one situation, and as bad as no design for any situation that doesn't fit. A lot of patterns may indicate that the engineer sat down with the book and went through the index putting in as many as possible (and some may be being used to deal with the poor fit of others of them).
        • Proper application of any tool and abandonment of good design principals is obvious enough to where it doesn't (or shouldn't) have to be stated.

          Misuse of anything will result in crap. Over compliating a system with unecessary farkles (whether they be patterns or not) is not a problem with patterns, it's a problem of poor design philosophy.

          That being said, high pattern density in any system design will result in a better design than one with lower pattern densities.
  • by taeric ( 204033 ) on Tuesday November 05, 2002 @11:44AM (#4599597)
    Maybe overusing isn't the correct term, but definitely blindly using. I have seen far too many times (in far too short a time) where people will just start tossing in as many "patterns" as they can.

    Sometimes, as if to really horrify me, the reasons for including a pattern are to appease a manager!! This really frightens me, as the patterns are not discussed at the planning stage, but as an afterthought to implementation.

    Which brings me to a question. I have always viewed design patterns to be something that are used during the planning phase of a project. All too often, I am seeing where people start trying to shoehorn a design pattern into a project because they just heard about how great of a job it does at something. Does this happen elsewhere, or just with the projects I see?
    • Of course. I once had a client, after a project was finished and in management validation for going public, suddenly go to www.commentcamarche.com or equivalent (www.howstuffworks.com is the anglophone site of similar nature) and pick up something about quality control and project management and suddenly start changing everything, including our reports, into terminology and methods he'd read the night before. A nightmare, since everything had *already* been managed reasonably and was working to boot!
    • I have always viewed design patterns to be something that are used during the planning phase of a project. (Emphasis added.)

      Design and planning are partners in crime. Trying to use design patterns "as an afterthought to implementation" is a really bad idea.

      I really laughed when I read your post, because I imagined another book, "Kludge Patterns." When you're well past the design phase on your application, and the damned thing doesn't work, abandon Design Patterns and riffle through the pages of Kludge Patterns looking for some clever hack that can save the day... =)
    • Which brings me to a question. I have always viewed design patterns to be something that are used during the planning phase of a project.

      Are you a coder or a planner?

      In the "real world" (tm) there is no clean separation between the "design" and the "planning" phase - because things change.

      In real projects things happen iteratively - you design and code a little, see how things are going, then amend the plan, and go back to coding. In between you ask the users to see if they thought of new requirements.

      Google "Extreme Programming".

      • This reminds me of why I despised the CS department in college. They thought that they were a completely unique subject that had to be taught completely differently then any other subject. What was the result? They were having to learn lessons that every other department had learned years ago. That is the one thing I absolutely loved about the Design Patterns book, the fact that they took cues from other disciplines

        So.. First off, There is no "real world." Anyone who uses that phrase is often about to explain an excuse for why they do something the way they do.

        However, I was not saying that I think there is an exact point where planning ends and coding begins, but they should be at least sheilded from each other.

        If somebody comes in with a whole new pattern of approaching a situation, perhaps they should realize they either never had a pattern (or plan) of approach before, or that they should finish the first approach. If it is the former, that is the problem. If the later, well, suck it up and finish it.

        Too many times you get people who think they should immediately apply the latest and greatest approach to a project that is still in the implementation phase of an older approach. That is a horrible mistake for people to make.
      • Are you a coder or a planner?
        In the "real world" (tm) there is no clean separation between the "design" and the "planning" phase - because things change.

        Actually, it's this whole viewpoint why I think Design Patterns & Refactoring go together like PB&J...

        One of the reasons why I like working with other people who also understand design patterns is because it simplifies a LOT of communication - instead of having to repeatedly describe an entire architecture, you can just say "I used the Abstract Factory pattern, and these are the names of the relevant objects", and then everyone knows what you're talking about (and can sanity check your code in a review to tell you if you violated the pattern somehow).

    • Even worse is people assuming that all patterns are good for is what is discussed in the book's examples. For instance, most developers can only apply the bridge pattern to GUI development because that's the example GoF used in their text. It's pretty sad that people find it so hard to translate one problem domain to another.

      The other danger of patterns is that certain developers only understand a couple of them really well and they become their 'favourite' patterns. Then every piece of code they touch has to implement one of their three pet paterns. And god forbid if one of those patterns is a 'Singleton'...

    • People do the same thing with XML too...
  • by goodviking ( 71533 ) on Tuesday November 05, 2002 @11:47AM (#4599610) Journal
    This is a fantastic book. It is probably the best book out there for coverage of all of the fundamental design patterns. The examples are in Smalltalk and C++, and are readable and easily translatable to other OO langs (Java, C#, ...).

    I would recommend that along with this book, you take a look at Pattern-Oriented System Architecture [barnesandnoble.com]. It applies the design pattern concept to problems in large scale system architectures.

    A combination of the techniques in both of these books can really help unwind alot of the spaghetti problems at both a system and component level. Additionally, alot of the fundamental concepts in modern system architectures become alot clearer once you've read both.
  • by cheezfreek ( 517446 ) on Tuesday November 05, 2002 @11:47AM (#4599613)
    Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.

    Even with no exposure to patterns, I was easily able to understand this book. This book was my first exposure to patterns, and I don't think I could have had a better introduction to the subject. I highly recommend this book to anyone who knows anything about object-oriented design.

  • When I was taking CE courses design I was fascinated by the Design Patterns book. I thought it would take OOD concepts one step further and offer a new framework for software development. I went out and bought the book, and while it was very interesting, I never really thought that I would be in a position where I could use any of the patterns.

    They seem overly complex, and although they try to be general, I can't imagine that they could be easily adapted to any but a few (large) software projects. I don't have enough good examples, but I get the feeling that every major software project will come up with its own "design patterns", and they probably bear little resemblance to the ones in the book (and will be a lot simpler as well). My wife likes them, and she thinks that they provide a common vocabulary for developers to use in developing their own patterns, although I am not convinced.

    What has been the experience of /.ers who actually use this book in their (non-educational) software development projects?

    • by Vengeance ( 46019 ) on Tuesday November 05, 2002 @12:00PM (#4599702)
      I use patterns on a regular basis, at many levels of code. The best description I've seen for why we want to use design patterns actually came across my desk this morning. If two woodworkers wish to describe joining two pieces of wood together for the front and the side of a drawer, they COULD, I suppose, discuss cutting a certain length, turning at a certain angle, cutting another length, turning the other way again, etc. etc. ad nauseum. OR, they can simply indicate that they want to use 3/8"-wide through dovetails.... Concise, and providing just as much information to the informed. What happens is that there is meta-information underneath the words being used, conveying more than the casual observer might catch. When discussing whether to use one pattern or another, it's akin to deciding whether you wish to use dovetail or mitre jointing for that corner. When you write code, you're already using patterns behind the scenes anyway. It's nice to know what you're doing, and it's REALLY nice to have a shared vocabulary for this stuff.
    • by oops ( 41598 ) on Tuesday November 05, 2002 @12:01PM (#4599716) Homepage
      Any good OO programmer/architect I know will speak in terms of patterns. eg. conversations I had yesterday went like:

      Can't you use a singleton here ?


      Perhaps we need a strategy mechanism

      and so on / so forth. As soon as people talk in terms of patterns, they're talking at a level of abstraction above basic objects, and at a level where you're talking about object construction and interactions. Whenever I see someone's CV claim to have knowledge of OO, pattern knowledge is the next thing I look for. It means that we can talk in common terminology and have a common 'toolbox' of solutions to use.
      • As soon as people talk in terms of patterns, they're talking at a level of abstraction above basic objects, and at a level where you're talking about object construction and interactions.

        This also helps when you're trying to wrap your head around a library written by others. Some of the clearest and best use of design patterns I've seen is in the Open SceneGraph [openscenegraph.org] library. Although a little short on tutorial docs, the code is so well designed (including naming!) from a patterns point of view that you can pick up what the various classes are doing very quickly.I wouldn't quite recommend it to a beginner in patterns but for someone looking at exactly how they are used in the real world, it's great code.
    • As a C++ and Java developer (7 years dev experience), I use several of the patterns very frequently. In order of usefulness in my career:

      Composite pattern
      Iterator!! (used in STL and Java Collections)
      Proxy (used implicitly in Java RMI)
      Prototype factory
      Observer (Java listeners, document-view architecture)
      Template method (used basically any time you do polymorphism)

      I'm astounded that people with OO design experience who've read the book can claim that they don't use the patterns! Several of the patterns are more esoteric, but I would have to say I have used virtually every pattern in the book at one time or another.
      • You mention Iterator, and the discussion of Iterator is representative of much of the book.

        Suppose I want to implement my own Iterator rather than relying on STL. The idea that there should be a collection object and a separate "cursor" object to point into the collection object is good. I then look at their example. The collection is a linear list which which exposes a public reference to GetItemAtIndex(i). All the cursor object does is keep a private copy of int i and does a GetNextItem() by i++ and calling GetItemAtIndex(i) on the collection.

        Ok, ok, they need a simple example to show the basic concept. But if a collection has a GetItemAtIndex(int i) method, I fail to see why I need the cursor object except as a wrapper around an int i. To me, the Iterator pattern is interesting if the collection is implemented as a linked list and if GetNextItem() actually interacts with the collection on the level of traversing the list.

        So the Iterator pattern needs to give the cursor access to some of the non-public workings of the collection, so as to not break encapsulation of the collection while making the cursor efficient in its access. A Google on Java Iterator turns up the use of inner classes on the collection to do just that. I didn't find anything C++ specific, but I imagine that the cursor could be a friend class to the collection class.

        I would like to see some more concrete examples on how to implement GoF in both C++ and in Java that solves some of the technical details of how to pull these patterns off. Yes, I know about C++ friend and Java inner classes, but I would like to see the GoF show what implementations they have in mind and to comment on usage of, say C++ friend declaration, in terms of advantages and pitfalls in terms of the degree of coupling between cursor and collection and what are good design practices in terms of trading off efficiency for encapsulation.

        GoF is good at the conceptual level but weak at the concrete level.

        • But if a collection has a GetItemAtIndex(int i) method, I fail to see why I need the cursor object except as a wrapper around an int i.

          There are two possible answers. 1: You don't. 2: Because you have other code that uses the iterator (e.g. because of templates (STL) or inheritance (Java collection framework)).

          So the Iterator pattern needs to give the cursor access to some of the non-public workings of the collection, so as to not break encapsulation of the collection while making the cursor efficient in its access.

          Why do you not want to break the encapsulation of the collection? Ok, I guess you want to do for some reason. If so, then yes, a friend class would be ok. And so would a nested class, which according to the latest C++ standard suddenly was allowed to see all members in the parent class.

          but I would like to see the GoF show what implementations they have in mind and to comment on usage of, say C++ friend declaration

          It is too bad then that the book fails to satisfy you. Personally, I have no wish for even further C++ bias in the book.

    • but I get the feeling that every major software project will come up with its own "design patterns", and they probably bear little resemblance to the ones in the book

      The design pattersn book contains 23 patterns. It is a sign of it's greatness that since then, patterns have become a hot topic, but no-one has been able to produce a list of another 23 generic patterns as widely applicable.

      In other words: You're wrong. They got most of them.

      Having said that, some of these 23 are more common than others. Particularly I have coded/seen/used these ones: Abstract factory, Factory method, Singleton, Adapter, Proxy, Iterator, Observer, Visitor.

      The most common of these are becoming ubquitous. Have you never used a single instance of a global var? that's a singleton, almost, and it's a good idea to go the whole hog and enforce uniqueness. Most langauges handle DB recordsets with an iterator or something very like it. Event multicast is the observer pattern.

      It is possible to overuse/abuse patterns. I've seen code where a 'designer' has latched onto the 'abstract factory' pattern and used it as a 'golden hammer' (See Antipatterns - another fine book mentioned in other posts here)

    • Damn right! My copy of 'Design Patterns' has sticky notes sprouting out of it all over, coffee stains and every other indication that it is something I use all the time.

      Let me point out that I have owned the book since it came out and have already been through the 'Maybe this *is* a silver bullet.' stage to arrive the 'No silver bullet, but damn useful.'

      What are design patterns good for? Well, certainly not slavish adherence to a particular way of doing things. However just about every pattern in the book (and others discovered since) is really something a good programmer knows already. But the book provides a shorthand 'language' and nomenclature for discussing object designs.

      And the use of patterns has some emergent qualities as well. Sometimes thinking about your designs in this way allows you to more easily see connections, opportunities and traps you might otherwise have missed...

      Jack William Bell
  • by eddy ( 18759 ) on Tuesday November 05, 2002 @11:50AM (#4599644) Homepage Journal

    What the review missed to point out (okay, I only gave it a once over..) is one very important aspect about patterns and this book in particular; it gives developer a new common language to use when communicating about software design.

    For instance, you might have 're-discovered' the visitor pattern yourself and used it several times, but without the nomenclature of this book it was very hard to actually talk about that design with other developers.

    Great book, one of few that - after reading it - got me all exited about development again.

    • by Anonymous Coward
      Most of that stuff in that book is trivial.

      Anyone who does real development was using these patterns years before the book came out.

      Books like these are catelogs of other people's ideas and put into a standard format. It is like saying that noone could breath oxygen before the perodic table of the elements came out. Obviously oxygen was around for ever. The patterns in this book are DESCRIPTIONS of other peoples work. It was the method of presenting the ideas that seemed new at the time.

      But when it comes right down to it JAVA or C++ classes do a much better job of documenting good design patterns for programming.

      The idea of Design Patterns is probably something developed by patent mongerers. They take very simple and trivial ideas and make them seem important by putting them in a common format. Big deal.

      You'd be better off reading working code than wasting your time on a five year old book that documents 15 year old ideas.
      • Sure it's trivial. Much like the "trivial" civil engineering concept that a bridge built with too little concrete will fall down.

        Certainly, anyone who does "real" (as opposed to integer?) development will have discovered many, if not all of these patterns. Why wait years, when you can read about them? Patterns are studied in architecture - and humans have been building structures far far longer than they have been crafting software.

        Sure it's a catalog. It's also a lexicon. Does that invalidate it's utility? This is the kind of work that will help push software development into a estimable science instead of the craft it largely is today.

        Java(tm) and C++ and are excellent ways to document implementations of systems. However, a design pattern is intended to be an abstraction that can be applied to ANY language. That way, a Smalltalk developer can say "Strategy" to a Java(tm) coder and they both share the appropriate context.

        You seem rather hostile about this book, resorting even to ad hominim attacks upon the GoF, who have separately and collectively done a great deal to advance OOP. Perhaps you regret not having written down these obscenely trivial ideas yourself and peddling your own brand of software snake oil.
      • Holy mackerel, you have completely misunderstood.

        Anyone who does real development was using these patterns years before the book came out.

        Books like these are catelogs of other people's ideas and put into a standard format.

        Exactly right. That's what the whole idea of documenting patterns is about. A pattern is always something that has been done before, never an experiment. People who document patterns are not inventing them (because an invention cannot be a pattern); they are identifying and naming successful structures and ideas that were not well recognized until then.

        The advantage is simply that we often don't see these things until they are named and described. We use them unconsciously, but may not recognize when there is an opportunity to re-use them, may not have thought carefully about when it is and is not advantageous to use them, and don't have the vocabulary to communicate them to other programmers.

        It is like saying that noone could breath oxygen before the perodic table of the elements came out.

        No, it's like saying we always had oxygen all around us, but it didn't have a name and no one really understood its properties until Lavoisier discovered it.

        But when it comes right down to it JAVA or C++ classes do a much better job of documenting good design patterns for programming.

        Uh, are you aware that some of the Java library classes were specifically built to implement Gang of Four patterns? Look, for example, at the Observer class and Observable interface from java.util.*; does that remind you of anything?
      • You probably think design meetings are a waste of time, too. Well, with common nomenclature such as presented in this book, those meeting are less of a waste of time. And I find those little "meetings" that occur in my head when I'm thinking about the design of a program I'm working on are more productive, too.

  • antipatterns (Score:5, Informative)

    by Aniquel ( 151133 ) on Tuesday November 05, 2002 @11:52AM (#4599653)
    If you read Design Patterns, the next book to read should be AnitPatterns: Refactoring Software, Architectures, and Projects in Crisis (ISBN: 0471197130). Design patterns shows you what to do, Anitpatterns shows you what *not* to do (and how to fix it if its already fscked up).
  • bn.com actually beats out Amazon by $10. [amazon.com]
    Design Patterns[associate] is $54.99. Compared to $44.95 at bn.com.

    Go ahead and click on Slashdots link.
  • Hell no (Score:4, Insightful)

    by PissingInTheWind ( 573929 ) on Tuesday November 05, 2002 @11:59AM (#4599701)
    [...] little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change.

    Holy shit no. 1992 isn't 'ancient' in any way, only for people with very short memory and attention span. Or for people who thinks XML is a neat new idea. Or for people who thinks Java OO-model is a neat new idea. Or for people who thinks Patterns is the new silver bullet. Or for people who thinks Lisp is dead.

    Hope you get the idea.
  • by avi33 ( 116048 ) on Tuesday November 05, 2002 @12:04PM (#4599723) Homepage
    Antipatterns [amazon.com] is a fine accompanyment, imho, it should be a prequel to DP.

    It describes the various symptoms of overdesigning a system, and how to rescue projects that have gone so far that the only option seems to be a ground-up redesign or a 10-year implementation. Plus it's funny, too, we'd all recognize our own programming methodologies (overbearing perfectionism in design) and shortcuts (gross hack that no one will ever see anyhow).
  • by Waffle Iron ( 339739 ) on Tuesday November 05, 2002 @12:06PM (#4599745)
    Book learnin' is fine and all, but here are some design patterns from the real world:

    The Demo design pattern:
    Boss: We need to have a working demo by the trade show next month.
    Developer: OK, but it's just going to be a barely working hack. There's no time to do any proper design by the show. It's going to push back the ship date because we're going to have to rip out the kludges and redo them properly.
    Boss: Fine. Just get me that demo.

    The Ship date design pattern:
    Boss: We need to ship the product by the middle of next quarter.
    Developer: We don't have time to fix the demo hacks by then. We need more time to do a proper design. I told you that the ship date would be pushed back by the demo.
    Boss: Everybody saw it working at the show, and they wonder why they can't have it now. We have to go with whatever you've got.

    The Beeper Design pattern:
    Boss: Support has been getting a lot of calls from customers in the field. A lot of random crashes. We need to have a developer available 24x7 to help debug these problems. Here, take this beeper.
    Developer: I told you so.
    Boss: We need to get a demo of version 2.0 by the field sales seminar next month.
    Developer: Aaarrghhh!

  • by eric2hill ( 33085 ) <<ten.kcaji> <ta> <cire>> on Tuesday November 05, 2002 @12:07PM (#4599755) Homepage
    Have a look at Best Book Buys [bestbookbuys.com]. They've got pricing for most books both new and used. Searching for Design Patterns [bestwebbuys.com] currently shows a book for $35 used and $45 new.
  • Read the book, because it's good. Lots of it will make obvious sense. Use that stuff. Some of it will seem like a stretch. "You're calling that a pattern?" Don't use that stuff.

    Programming is about basic principles applied intelligently. If it's complex, it's probably not right. You have to sift through the ideas of the week, such as template-, OO-, component-, and pattern-based programming, to find the right way to solve a particular problem.
  • Which, I think, is actually a problem with
    the way some people think, to my great annoyance -
    is that now every problem has to be thought
    of only in terms of one of these patterns,
    and [your favorite deity or lack thereof] forbid
    you actually come up with something new...
  • Design Patterns are important because they suggest that Software Engineering might actually have some content beyond regular CompSci courses.

    My school has Bachelor's degrees in both CompSci and Software Design the primary difference being that Software Design students are required to take all the Software Engineering courses while CompSci students get to choose. There was a heated discussion at a recent Dept. meeting over whether CompSci students should be allowed to take the full-credit capstone project in Software Design; it was decided that they should only be allowed to do a half-credit project: "otherwise there'll be nothing to differentiate the Software Design degree".

    Now Software Engineers can sit around and learn various patterns for four years, which is exactly what industry wants them to be doing. After all, with a 4-year degree you should be an architect managing diploma-holding-code-monkeys rather than actually writing code yourself. Computer Scientists will have no use for such courses, pointing out that they've had their own "patterns" all along: they're called "algorithms".

  • Design patterns is the distillation and categorization of the most useful kinds of objects. Should be required in any computer curriculum.
  • If you are interested in design patterns and are looking to use them, then this should be one of the books on your shelf.

    That simply isn't a strong enough statement. If you're doing object oriented programming, you owe it to yourself to at least borrow a copy to read.

    Design Patterns is not about telling you how to program. It's about discovering that lots of random, unrelated things you've been doing for years are actually related. It's about building a common language with other programmers about things you're already doing instinctively. The book starts by explaining that the patterns weren't created, they were discovered. Once they began looking for patterns, they found them everywhere. And when you see the patterns, you'll often go "Hey, I've been doing that for years, but I never really thought about it!" The book is about stepping back a bit from your work to discover patterns you've overlooked even as you implemented them. The perspective on other similar projects and teh analysis of common uses will help you apply solutions you already know to new problems. This is a great book.

  • by Brad Lucier ( 547713 ) on Tuesday November 05, 2002 @12:54PM (#4600132)
    Peter Norvig explains [norvig.com] why many of the classical design patterns used in C++ or Java are trivial or not needed in dynamic languages like Common Lisp, Scheme, and Dylan, and presents new, more powerful, design patterns for dynamic languages.

    Richard Gabriel thinks design patterns are important, but he also believes that the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less [google.ca].

    • the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less

      Pandering to 'wannabie elite hackers' is now enough to earn +5 informative? Jesus!

      If our Industry cannot develop the tools to move on from a hacking culture to a Proffessional Software Engineering culture, we may as well all give up and go and go back to living in mud huts.

      The most simple fact is that Patterns (and the GOF) are to software engineering what Whitworth was to the Industrial Revoulution, the ubiquitous standard that make it possible for a spanner manufactured in Sheffield to tighten a bolt from Africa in a Bridge in Deli.

      Try the following for a better insight into the importance of standards in creating a revolution.

      http://www.wired.com/wired/archive/10.01/standard s .html

      It's not the ignorance in postings that disappoint it's the ignorant moderation.
  • Two additions... (Score:2, Informative)

    by \/\/ ( 49485 )

    "Design Patterns" really is an excellent text that everybody doing OO design/programming should read.

    While you're at it, pick up the books that inspired the idea of "design patterns" for OO design: Christopher Alexander et.al.'s books on architecture, especially A Timeless Way of Building (introduction to the idea of patterns) and A Pattern Language: Towns, Buildings, Construction, which contains their pattern catalogue (there's a third one in the series which I haven't read yet that describes the application of some of the patterns in a real-world example). Both books are beautifully written, accessible to non-architects, and (interestingly enough) seem to be more popular with computer science people than with architects.

    Back to the CS design patterns, the reason why most of the examples draw on UI techniques probably stems from the fact that most patterns result from the author's work on the ET++ framework, which was quite popular in the early 90's (one of the first integrated software development tools for C++, SNiFF, was build with it -- very nice software before it became yet another commercialized packaged bloatware thingy.)

  • by puppetluva ( 46903 ) on Tuesday November 05, 2002 @01:07PM (#4600211)
    Design Patterns - arguably one of the most important books of all time in software design got an "8". I figured it would get a "10" because of its relative importance. . . so

    I went to look at other recent slashdot reviews to see what other books design patterns compares to. The results are hilarious:
    • 7.5 - The Legends Of Dune - Volume 1: The Butlerian Jihad (Design patterns barely beats it, evidently I should be torn between these two books at the bookstore)
    • 9 - Linux Prgramming by Example (A "by example book" blew away an architectual classic.)
    • 10 - Dynamic HTML The Definitive Reference (2nd edition) [Evidently this groundbreaking tome on DHTML is in another class from "Design Patterns"]
    • 8.7 - Extending and Embedding Perl (The message here is - if "Design Patterns" is on your shelf, may only be a bookend to "Extending and Embedding Perl".

    I think that we should have a way to vote reviews "fair, underrated, or overrated" (and have that change the ranking) because it is clear that books with limited applicability (some only a blip on the technology horizon) often get rated better than truly groundbreaking pieces.

  • An alternative to designing software using patterns is to refactor [barnesandnoble.com] code toward patterns.

    This is considered one of the best ways to use patterns by many in the patterns community -- especially to avoid the "little boy with a pattern" syndrome described by many here.

    For more on this idea, and on patterns in general check out the Portland Patterns Repository [c2.com]. There is also a conference every year about patterns called PLOP [uiuc.edu]

    Finally, the software patterns community owes its origins to the Architectural (think buildings not code) Patterns world. Christopher Alexander [utsa.edu] is considered the father of patterns. His books A Timeless Way of Building [barnesandnoble.com], and A Pattern Language [barnesandnoble.com] are technical, dry and expensive, but considered fundamental to truly grokking patterns.
  • I heard recently in a talk (by Craig Larman) that it was Kent Beck of Extreme Programming fame, and not the Gang of Four, who originally came up with the idea of applying Christopher Alexander's "pattern" concept to software engineering.

    Can anyone confirm or deny that?

    Of course even if that is the case, the G4 deserve very much credit for taking the idea into so much depth. But in fact like many other people, I had believed that it was Erich Gamma of the Gang in particular who had developed the concept.
  • by Tablizer ( 95088 ) on Tuesday November 05, 2002 @02:37PM (#4600643) Journal
    GOF (Gamma, et. al.) Patterns show a primary flaw in much of OO philosophy IMO. The equivalent "patterns" in a procedural/relational (p/r) approach will typically involve roughly 80 percent relational query(s). IOW, "formulas" instead of "patterns". Formulas are not only more compact, but don't clutter up the larger-scale structure of the code. (LISP fans say similar things about GOF patterns, I would note).

    The "noun model" is mostly via the database in p/r, and is "virtual" rather than a physical code structure. GOF patterns thus look primitive, or "pre-virtual". Database designers in looking for common threads to managing noun models, discovered "pattern formulas" in the form of query languages, especially relational query languages.

    OO structures like those found in this book tend to reinvent incremental parts of database techniques from scratch each time. The programmer has to hand weave most of the interrelations and "indexing" between classes. The result is similar to the "network databases" that fell out of favor in the 1960's. The GOF Patterns movement is mostly a rehash of technology and philosophy that died in the early 70's, as variations of Codd's relational model proved superior.

    Thus, you are not only reinventing a (halfass) database with GOF, but reinventing an out-of-style one on top of that. A double-whammy no-no in my book.

    Dare I say "Disco Patterns"?

    If one understands how to use relational databases and technology properly, their need for GOF Patterns greatly diminishes IMO. I know I will take lots of heat for this, but it is what I believe. (Some niches may vary due to special requirements or equipment limitations. But I would note that 1980-era lite-duty DB's ran in like 64K.)

    (Is it just me, or is slashdot having network difficulties today? This is the 3rd repost try.)
  • One guy who has done a lot with this is Joshua Kerievsky. He has a good guide to study patterens on his site, and has made a start at a book which makes patterns fit into the overall development process as part of the refactoring phase. I've gone through it once, and wil be the first to admin it needs some copy editing, but the idea is sound. Anyone interested can check it out at
    http://www.industriallogic.com/xp/refactoring/ [industriallogic.com]

    Check out the rest of the IL site as well, as there are good resources there.
  • by prizog ( 42097 ) <novalis-slashdotNO@SPAMnovalis.org> on Tuesday November 05, 2002 @03:19PM (#4600957) Homepage
    Dominus gave a hilarious and insightful talk at YAPC 2002 about Design Patterns, titled, Design Patterns Aren't [plover.com].
  • I'll definitely second (twentieth?) the recommendation of this book.

    An interesting more recent development in the design community is the concept of "antipatterns" -- that is, common design and code constructs that people use frequently that are wrong (or at least risky, inefficient, or otherwise suboptimal). I just finished reading Bitter Java [bitterjava.com], a book about antipatterns, and found it extremely thought-provoking. Sometimes knowing what not to do is even more helpful than knowing what to do.

  • A lot has happened within the field of patterns since 1995.

    Each year there is seven patterns conferences held around the world. At each of them 15-50 patterns or pattern languages are workshopped and published in book form. Got to http://www.hillside.net/ and click on "conferences" to learn more of the conferences.

    The form has evolved a lot since the Gang of Four book was published. Pick up the proceedings for a recent patterns conference to see for your self.

    The largest repository of patterns are the proceedings for all these conferences. Unfortunately they can be very hard to get hold of unless you attended the conference at which the pattern you are interested in were workshopped or can borrow the proceedings from someone who attended.

    There is a set of four books published by Addison Wesley and easily obtainable, that are a collection of the best patterns from the first four years of these conferences.

    http://www.aw.com/catalog/academic/product/1,409 6, 0201607344,00.html
    http://www.aw.com/catalog/acad emic/product/1,4096, 0201895277,00.html
    http://www.aw.com/catalog/acad emic/product/1,4096, 0201310112,00.html

    In one of the posts above someone asked if the "Design Patterns" book was obsolete by now, because it is seven years old. Patterns are solutions to problems that arises again and again, and for which there is a solution that has been succesfully used in several independent cases. So patterns are in starch contrast to the API of the month phenomenon.

  • by g4dget ( 579145 ) on Tuesday November 05, 2002 @04:12PM (#4601444)
    You should know about design patterns. They simply are a clear statement of object-oriented techniques that programmers have known about for decades. Think of it as a grammar and hanbook of style for programming languages.

    But design patterns also show fundamental flaws in the object-oriented languages: design patterns are abstractions for which object oriented languages have no support. While object oriented languages have support for data structures and encapsulation in the form of type checking and access specifiers, when it comes to design patterns, you have to put them in by hand, document them by hand, and make sure they are working correctly by hand. Design patters are to object oriented languages like nested loops and data structures are to assembly language: you can implement them, but the language isn't going to help. The problem is that object-oriented languages really build abstractions out of individual classes and that individual classes are the units of abstraction and encapsulation, while design patterns require abstraction and type checking at the level of groups of classes. Attempts at supporting design patterns explicitly in object oriented languages so far also have been unsatisfactory as far as I'm concerned.

  • The GOF book is great, no questions. When I
    was a C++ programmer, it was my bible.

    When I switched to Lisp, I discovered I didn't
    seem to need most patterns anymore. Seems I'm not
    the only one to have made this discovery; a well
    known lisp expert, Peter Norvig, shows us why
    half the patters in the GOF book are not required
    in more powerful languages: http://www.norvig.com/design-patterns/

    The upshot is that most patterns are required
    because of C++'s lack of powerful abstraction

"Any excuse will serve a tyrant." -- Aesop