Design Patterns 314
| 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. |
Introduction
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.
Conclusion
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.
Summary
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.
Chapters:
1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion
Appendix:
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.
Learn from the masters (Score:5, Informative)
However, for all the knowledge it contains it has a price tag to match. If you can get it used and cheap, do so.
AC
Re:Since the author didnt mention it... (Score:5, Informative)
Bruce Eckel has one in development available here:
http://www.mindview.net/Books/TIPatterns/
There are other places too:
http://www.csc.calpoly.edu/~dbutler/tutoria
See what Google brings up for you.
Re:Since the author didnt mention it... (Score:5, Informative)
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.
Re:Since the author didnt mention it... (Score:3, Informative)
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.
Important point that the review might have missed. (Score:5, Informative)
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.
antipatterns (Score:5, Informative)
Re:Who Actually USES These Patterns? (Score:5, Informative)
Re:Who Actually USES These Patterns? (Score:5, Informative)
Can't you use a singleton here ?
or
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.
For those who don't know... (Score:3, Informative)
Re:Since the author didnt mention it... (Score:1, Informative)
I'd recommend reading it more than buying it; if your experience is similar to mine then you will probably end up going through it once or twice, thinking "ah, I used that in such and such a design", use it as a reference once or twice and then leave the book sitting on a shelf gathering dust. It has changed the way I design systems (for the better) but I also found that it was quicker to build up an overall understanding of unknown code written using patterns, simply by spotting where they're used.
There's a lot of information in the wiki at www.c2.com; it's probably useful to read:
http://www.c2.com/cgi/wiki?PatternsForBeginners [c2.com] provides a reasonable introduction.
http://www.c2.com/cgi/wiki?DesignPatternsConsider
The patterns themselves can be dangerous, as I've found myself on some occasions, as they foster a detachment from the implementation details. There is a tendency to knock out code quickly because you know the design well, but the resulting code contains subtle flaws that aren't considered in the GOF book.
Alexandrescu's book, Modern C++ Design, discusses the implementation of factory patterns, visitor and singleton, which is regarded as being one of the simplest patterns to understand but hard to implement well. Apparently one of the authors of the GOF book once stated that he wished singleton had not been included in the book.
For interest, perhaps look at [c2.com]
http://c2.com/cgi/wiki?SingletonsAreEvil
It's worth buying if you can't find a copy to read and you have the spare cash at some point, simply because it can be hard to find information on some of the less used patterns in the book on the internet.
Hope this rambling is useful.
Re:this book is out of date (Score:3, Informative)
And is still perfectly relevant. Writing SW hasn't changed that much in the last 5 years.
>You would be better off now to read through the JAVA class documents.
This may help if you want to know how to write a nice class, but patterns are about getting good interactions between classes, they look at things at a much higher level of abstraction. This is one reason why they can add to a programmer's vocabulary.
>Design Patterns that are published in a book like that lag the real practices of the software industry by many years.
And they have been superceded by what exactly?
>Folks who work in software lead the industry, they don't live in the publishing houses or in the ivy covered hallways of money mongering corporate universitys.
Oh, and they never talk to each other? If I think I'm leading the industry, how do I go about spreading my fabulous ideas? Hey, maybe publishing a book would be a good way?
>Now it is OUT OF DATE.
No it is NOT. All the ideas are still valid, all the problems are still around, and the basic concept of patterns has spread enormously, so that now you get anti-patterns, analysis patterns, project management patterns etc. etc.
Design Patterns help "losers lose less" (Score:5, Informative)
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].
Re:a great, but dangerous, idea (Score:3, Informative)
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...)
Two additions... (Score:2, Informative)
"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.)
Refactoring to Patterns and other Resources (Score:2, Informative)
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.
Re:ya, I couldn't talk till I saw that book (Score:3, Informative)
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.
Re:ya, I couldn't talk till I saw that book (Score:3, Informative)
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.
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.
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?
Patterns conferences - pattern languages - pattern (Score:2, Informative)
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,40
http://www.aw.com/catalog/aca
http://www.aw.com/catalog/aca
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.
Moderators - YHBT. HAND. (Score:1, Informative)
Tablizer [geocities.com] has some strong views on programming languages, which can generally be summed up as something like "databases are a programming language; all other languages are inferior to databases" [1]. For more details, feel free to try and twist your brain around his article on Table Oriented Programming [geocities.com].
His intellectual hostility towards anything except his own ideas (and object oriented programming in particular) is fairly well known, and been discussed to death [slashdot.org] on /. before. In short, this is a fellow who has ver likely never really bothered to try to understand design patterns, nor any other OOP concept, beyond the point of mastering whatever jargon he needs to start arguing his pet theory that databases are a superior programming language.
Tabilizer would do well to remember Carl Sagan's quote about genius...[1] For the record, this is my own summary of his position, not his own words.
Patterns point to language deficiencies? (Score:2, Informative)
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
facilities.