Slashdot Mirror
Design Patterns
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 StudyThis 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 PatternsThe 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.
ConclusionThe 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 ExtrasThe 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 IssueDesign 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.
SummaryThis 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.
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.
AC
I have never seen a code monkey in a well designed patterned outfit. I wonder if this book will help at all.
---
When you come to a fork in the road, take it! --Yogi Berra--
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.
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:
l s/wint er96/patterns/
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.
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.
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.
It was a joke! When you give me that look it was a joke.
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.
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.
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?
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.
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.
Belief is the currency of delusion.
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).
[...] 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.
A message from the system administrator: 'I've upped my priority. Now up yours.'
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.
It was a joke! When you give me that look it was a joke.
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 ?
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.
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!
I'll vouch for the book. It was one of the textbooks from a Programming Languages and Paradigms class that I took. The first 2/3 of the class was advanced Java topics, but it became significantly more interesting when we dove into design patterns.
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
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.
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.
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.)
Table-ized A.I.
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??)
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
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.