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.
Since the author didnt mention it... (Score:2, Insightful)
I have only limited funds, and I cant afford something that wont help me. So... all those who bought it, is it WORTH IT?
Thanks.
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:2)
I am a great fan of Bruce Eckel's work. I have read his in-progress book Thinking in Patterns with Java [mindview.net].
Either there is a lot less to design patterns than I hoped (unlikely) or the book doesn't cover enough basic material for me to understand. I think I am going to buy the Gang of Four book just to find out if I'm missing anything.
Re:Since the author didnt mention it... (Score:5, Insightful)
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.
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.
Re:Since the author didnt mention it... (Score:3, Interesting)
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.
Re:Since the author didnt mention it... (Score:2)
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
Re:Since the author didnt mention it... (Score:2, Insightful)
The book is about design patterns. How can it be antiquated? Unless you're still programming in BASIC...
Bob
Re:Since the author didnt mention it... (Score:3, Funny)
I think that sound... (Score:2)
...is the sound of a hundred /.ers picking up the GOF book and thumbing to page 18.
Oh, and he's right, by the way. :-)
Decide for yourself... (Score:4, Insightful)
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??)
amazon links (Score:2)
(though he'd probably get a lot of flak from ppl for making use of it, even though it is a legitimate referral. :P)
Re:Since the author didnt mention it... (Score:2)
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.
Re:read the first chapter at the book store. (Score:3, Insightful)
Something that you are most likely too young and inexperienced to understand yet is that you do not write code for yourself to maintain. A coder typically writes code and others will maintain it (because you left for another job, got promoted, the project was handed off to a maintenance crew, you got fired for your crappy work, or whatever). THEY have to make sense of your code to fix/maintain it.
If your code is cryptic and/or undocumented, it will cost your company/team lots of time (and time is money) and frustration to debug and/or modify it. Even if you are still in the group, someone else may need to go into the code that you wrote (notice that I did not say "your code" as it is not your code if you are working for a company or contributing to an open software project) to do something. If you routinely contribute such crap to open source projects, you will quickly be denied access to any further projects.
I think perhaps you read him wrong (Score:2)
I think perhaps you (and the AC who responded to the same post) have misread this post. While it was written in a flamey style, my take is that it's written by someone who has been there and done that plenty of times.
Look at the two big things that he (I assume) says.
Personally, I think there's a lot of truth in both of those. I disagree with his take on design patterns, in that I do value and use them. Then again, I've seen plenty of people who tried to work them into a design "just because". They are truly and completely missing the point of patterns. I'd rather work with someone who didn't see the point and avoided them than someone overly clever who tried to use them without a good reason.
Further, many (most?) managers are among the worst people in this respect. If you don't produce your 1,000 pages of buzzword-laden documentation this year, you're obviously not working hard enough. (These are the same people who judge productivity by how many lines of code you write per day.) It's a sadly overlooked truth that your code really should need little paper documentation if it's done properly, and the best low-level documentation -- indeed probably the only worthwhile low-level documentation -- is the code itself. Just follow some simple basic steps:
At this point, your paper documentation should be limited to something like:
Everything else really is just waste paper, yet how many projects have you seen where they print out what every single function does and file it away, even though 99% of it will be redundant next week since we changed everything? I have watched projects collapse under the weight of unhelpful or downright obstructive paperwork and procedures, and seen the light. :-)
So seriously, while this guy comes across as flamebait, just stop and ask yourself whether he's really a pimply 15-year-old L337 Hax0r, or whether he's a 20-year veteran who's seen it all before and knows that at the end of the day, working code and lightweight procedures are worth far more than any management buzzwords and formal process certifications you care to mention.
Of course, he could still be a 15-year-old s'kiddie, too. If he is, though, I think he writes with more than a slight ring of truth.
Re:Since the author didnt mention it... (Score:2)
If you didn't get the job on that basis, at least you know you didn't want to work there. After all, the smart-ass doing the interview completely missed the point of patterns. :-)
Designing Patents ?? (Score:3, Funny)
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:Learn from the masters (Score:2)
Re:Learn from the masters (Score:2)
Me, too (Score:4, Interesting)
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, a.k.a. The Gang of Four, did an excellent job. If you don't buy it, at least pick up a copy at Borders and skim it. You will be a better programmer for it.
Here's another good breakdown of the book [hillside.net]
Designing and Patterns (Score:4, Funny)
history lessons.. (Score:5, Insightful)
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.
Re:history lessons.. (Score:3, Insightful)
Next Up in the Obvious Category... (Score:5, Funny)
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.
Re:Next Up in the Obvious Category... (Score:3, Insightful)
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.)
Re:Next Up in the Obvious Category... (Score:2)
Re:Next Up in the Obvious Category... (Score:2)
n.
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.
Re:Next Up in the Obvious Category... (Score:2)
I'm just glad they have their target market so well defined.
Re:Satisfies "News for Nerds" OR "Stuff that matte (Score:2)
a great, but dangerous, idea (Score:5, Insightful)
Design patterns is important for every OO programmer to read, understand, and hopefully transcend.
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...)
That's because it's true (Score:2)
A system showing high density will, by defenition, be better designed that one without.
Re:That's because it's true (Score:2)
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).
Re:That's because it's true (Score:2)
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.
Re:That's because it's true (Score:2)
Any system can be abused. Patterns make system design relatively easy to convey. When "how does that work" question comes up in review, someone with knowledge of patterns will be able to provide a better solution than someone who just puts magic black boxes on the table.
This is like saying the more tools you take out of the toolbox the better carpentry job you do.
No it isn't. It's saying that you can't build a complex building without blueprints. Patterns represent known best practice designs. If you apply design patterns to all of your subsystems, you will end up with a superior design.
Beware of overusing patterns. (Score:5, Interesting)
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?
Re:Beware of overusing patterns. (Score:2)
Re:Beware of overusing patterns. (Score:2)
Re:Beware of overusing patterns. (Score:2)
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... =)
Re:Beware of overusing patterns. (Score:2)
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".
Re:Beware of overusing patterns. (Score:2)
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.
Re:Beware of overusing patterns. (Score:2)
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).
Re:Beware of overusing patterns. (Score:2)
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'...
Re:Beware of overusing patterns. (Score:2)
Great book, goes well with .... (Score:3, Insightful)
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.
Re:Great book, goes well with .... (Score:2)
Thanks Mr. Illuminati [sjgames.com], this here internet thingy sure does rock!
* Sigh *
If it makes you feel any better, here's another link to the book [wileyeurope.com] from the publisher. In my opinion, the barnes and noble link has more info, but this link might be less offensive. If you really want my bookstore marketing plug, I say buy the book at one of these locations [bookweb.org] and help keep independent booksellers alive. Regardless of your interesting take on my motives, it really is a fantastic book and is worth a look.
No pattern experience required (Score:5, Interesting)
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.
Who Actually USES These Patterns? (Score:2, Interesting)
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?
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.
Re:Who Actually USES These Patterns? (Score:2)
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.
Re:Who Actually USES These Patterns? (Score:2)
Composite pattern
Iterator!! (used in STL and Java Collections)
Singleton
Proxy (used implicitly in Java RMI)
Prototype factory
Adapter
Observer (Java listeners, document-view architecture)
Template method (used basically any time you do polymorphism)
Decorator
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.
Limitations of GoF book (Score:2)
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.
Re:Limitations of GoF book (Score:2)
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.
Everyone actually uses these patterns (Score:2)
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)
I Do! -- Was: Who Actually USES These Patterns? (Score:2)
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
Re:Who Actually USES These Patterns? (Score:3, Insightful)
The main good thing about this book is not that it lists a lot of patterns, but rather that it teaches you what a pattern is. This is truly a mind-altering experience. Once you grok the concept, you see patterns pop up all over your own code! Then you can extract and refine their specialties, encapsulate them and re-use them again and again.
This, besides saving you a shitload of future work, teaches you entirely new ways of thinking about object-oriented programming. I've talked to a lot of people who found that reading this book is truly a mind-blowing experience in that respect. Certainly changed my coding.
And the specific patterns in the book are kind of cool, too.
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.
ya, I couldn't talk till I saw that book (Score:2, Interesting)
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.
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:2)
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?
Re:ya, I couldn't talk till I saw that book (Score:2)
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)
This is a first (Score:2)
Design Patterns[associate] is $54.99. Compared to $44.95 at bn.com.
Go ahead and click on Slashdots link.
Re:This is a first (Score:2)
Hell no (Score:4, Insightful)
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.
must read 'antipatterns' as well (Score:3, Insightful)
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).
Real World Design Patterns (Score:5, Funny)
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!
For those who don't know... (Score:3, Informative)
best way to read this... (Score:2)
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.
a problem with patterns... (Score:2)
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 = Software Engineering (Score:2)
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".
Re:What exactly is a "pattern"? Need good def (Score:2)
1. Patterns: A way of structuring a computer program to achieve various goals such as robustness, maintainability, flexibility, ease of development, or whatever the author thinks is important. A pattern may or may not be obvious to different people, but usually some degree of non-obviousness is needed for somebody to actually write it down.
2. Algorithm: A recipe for solving a specific class of problems. It must be possible to prove that the algorithm always solves the input problem (if it is of the right class), and that it terminates in finite time. It must also be possible to write the algorithm in some imaginable computer language for some imaginable hardware.
3. Formula: A set of mathematical symbols thrown together in a syntactically meaningful way, intended to convey some meaning to the reader of the formula. It may also be used as the basis for a computation.
next step beyond objects (Score:2)
Doing OOP? You want this book. (Score:2)
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.
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].
Trolling earns +5 informative ? (Score:3, Insightful)
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.ama-cycle.org/features/whitworth.asp
http://www.wired.com/wired/archive/10.01/standar
---
It's not the ignorance in postings that disappoint it's the ignorant moderation.
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.)
Maybe Slashdot needs a Book Review Moderation (Score:5, Interesting)
I went to look at other recent slashdot reviews to see what other books design patterns compares to. The results are hilarious:
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.
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.
Kent Beck (Score:2)
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.
Obligatory Anti-Pattern Viewpoint (Score:4, Interesting)
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.)
Study Groups (Score:2)
http://www.industriallogic.com/xp/refactoring/ [industriallogic.com]
Check out the rest of the IL site as well, as there are good resources there.
Design Patterns Aren't (Score:3, Interesting)
Antipatterns (Score:2)
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.
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.
good to know about--but it's accepting defeat (Score:4, Insightful)
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.
good examples--you make my point for me (Score:2)
That's a good example, because it's another area where many commonly used languages fall short. Languages should support the abstraction of control structures, but most object oriented languages don't. This is indeed just as much of a deficiency in widely used OOLs as their lack of support for design patterns.
You're saying "walls are nice, but the problem with bricks is that they don't come pre-built into walls."
And that's probably why bricks aren't used that much anymore: in order to lower the cost of construction and improve its consistency, many walls these days are, effectively, created "pre-built".
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.
Re:Only shit coders read books like this (Score:3, Insightful)
Anyway, if you've got to write a low-level device driver, why are you using C++ at all? Get down to assembly level and do it right!
There are different types of problems out there that need solving. This book addresses ways of solving many of them.
Re:Only shit coders read books like this (Score:3, Funny)
Re:Classic Geek Book (Score:2)
Re:Classic Geek Book (Score:2)
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.
Re:CD (Score:2)
Re:CD (Score:2)
Design Patterns Source [hillside.net]
More Martin Fowler (Score:2)
Another site mentioned by Martin Fowler is Enterprise Integration Patterns [enterprise...tterns.com]. This site deals with patterns found when creating distributed enterprise systems.