Slashdot Mirror
Pattern Hatching: Design Patterns Applied
John Vlissides, a member of the "Gang of Four" -- the authors of Design Patterns, presents another book on the subject. In part, this book presents some important aspects in using patterns; hence the subtitle "Design Patterns Applied" is right on the spot. Vlissides shows when certain patterns are used in real life, and even quotes a lot of e-mail from other users, showing patten advantages and, notably, weaknesses. As Vlissides states, "This book conveys something very important that's missing in the more academic and published Design Patterns book -- that patterns are the result of real, working programmers who don't get everything right the first time, and who struggle with the pragmatics of recurring design practices" (page x). Herein lies the book's greatest strength. Another part is aimed for pattern writers, rather than users. Sadly, these is no clear separation between these two aspects of the book.
The book is basically a collection of Vlissides's columns in C++ Report, and this is arguably the book's weakest point: if you're not intimately familiar with the little details of C++, you'll miss much of the action. This is sad, because the original Design Patterns book was careful to present patterns in a relatively language-independent manner, both in C++ and in Smalltalk. Here, the view is strongly biased towards C++, in ways that sometimes would annoy (or amuse) users of other languages, such as Smalltalk or Java.
Consider, for exmaple, Chapter 3: "Themes and Variations". A large portion of the chapter deals with the de-allocation problem of Singleton objects. Any programmer who uses a garbage-collecting language will be simply amused by the entire hoopla. The only conclusion from the entire discussion, one that the author himself admits (p. 69 and elsewhere), is that the lack of garbage collection greatly increases design complexity, in addition to program complexity. A design that had the potential of being elegant turns out into an ugly monster by the need to manually manage memory deallocation. Not to mention the suggested use of "delete this" (p. 41). The author is "not sure why, but [...] people wince at delete this". Hint, John: objects sometimes reside on the stack. In which case delete this can have very... interesting consequences. (True, in the context of a Singleton, where allocation is controlled and cannot occur on stack, this specific problem is not present, and yet "delete this" is such an evil construct, with such horrible possible results, that I'd rather avoid it even in such controlled cases.)
And sadly, the entire discussion on the use of Singletons ignores what I've come to conlude is the pattern's worst, and most common, misuse: Singletons, in my experience, are a tempting (and in practically all cases wrong) replacement for global variables. A designer that finds a need for a global variable simply replaces it with a Singleton, and pronounces that not only he's not using globals, but rather he's using a known pattern, which must mean his design is good.
Chapter 2 is a tour-de-force of using "classical" patterns, those presented in the original Design Patterns book. The examples look a little forced, and life too simple (every problem has a corresponding pattern that fits it like a glove), and yet it is a most educating read. For one relatively simple problem, the author comes up with an elegant solution that uses no less than six patterns (Proxy, Composite, Template Method, Visitor, Mediator and Singleton) -- and suggests an enhancement using a seventh one (Observer). This discussion alone could be worth the effort of reading the book, as it examplifies the correct and practical use of patterns in real life. The end of the chapter presents a very nice kind of diagram, invented by Erich Gamma, which could be very useful indeed. This "pattern:role annotation", as Gamma calls it, allows people who are sufficiently fluent in the pattern language of design to immediately grasp the role of different objects, even in a large design.
Chapters 4 and 5 are aimed mainly for pattern developers, though this is not clear when one begins to read them. It includes an example of the Gang of Four's elaborate discussions about pattern design, with lots of quotes from e-mail messages, etc. This is interesting only to a certain extent. The discussion, basically, is about whether Multicast should be presented as a pattern in its own right, or as an adaptation of the Observer pattern. Most of the discussion seemed to be dealing with minute neuances, but the conclusion (the presentation of a whole new pattern, "Typed Message"), is a beautiful one.
The concluding chapter (5) is titled "Seven Habits of Effective Pattern Writers". The name says it all. Though some of the advice presented (e.g. number 5, "Presenting Effectively") are trivial, others (e.g. number 1, "Taking Time to Reflect") are very educating. (Don't be mislead by that simple title, "Taking Time to Reflect". Vlissides provides some real important tips under this seemingly obvious one.)
In conclusion, if you do a lot of object-oriented design, and use (or consider using) design patterns, reading this book can be a good use of your time; but unless you spend time on designing patterns, too, you might wish to simply skim the last two chapters.
Pick this book up at ThinkGeek.
For additional book reviews, please visit http://www.forum2.org/tal/books.
Excellent review, which almost forced me to buy the book. The finest thing about the patterns books are that we can all finally put the same names to practices we've used for years.
An Eye for an Eye will make the whole world blind - Gandhi
If you didn't understand a word of this review [and I've got to admit I came close] then perhaps this web site will help
Design Patterns
This is the homepage of the previous book in the series.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
I love patterns. I suspect that many /. readers are going to say "patterns - and all that OO stuff is just another software development technique that will die in five years".
It's not - and those of you who code large systems that are underfunded, and have too short deadlines know this.
Patterns - and to a certian extent - OO design, allow software development to become engineering, with all the advantages that brings.
In particular, reuse of subsystems has made (non-software) engineering a profession that produces reliable products most of the time.
If you compare that to software engineering, we are still in the early years of last century. Before standadised engineering components (girders, bolts, whatever) everyone had to make them for themselves. Now, you can just go and buy them and know how reliable they are.
Patterns allow us to develop systems in repeatable ways that are known (proven) to work. Combined with component reuse, I'm convinced they are the only way that we are going to be able to keep up with the increase in complexity of the systems we build.
The other advantage is that Patterns give us a shared vocabulary. Yesterday, I was discussing with another programmer how we could allow various parts of the system we are building to get notification of user logons and log offs.
He starts trying to explain this complex system of events, and callback registration, and I go - "The Observer Pattern?", he goes "Yep" and we both know exactly what we are doing. You can't beat that.
I don't know about this book - I'm not a big C++ fan anyway, but if you haven't read about patterns get yourself the Gang of Four's book and do yourself a favour.
The fact that the book is focused on C++ stems from the aim of the book that is to show the patterns applied. If he settled for some abstract or rarely used lingo would that be showing design patterns applied?!
I think the discussion on the Observer is the best I have ever read and the treatment is solid and all tradeoffs are discussed. It's a pleasure to read and very enlightening approach to the Most Misused Pattern in the World(tm).
By all means ignore this review and pick up a copy. It's a masterpiece from a guy that really knows what he's on about. If you understood the GoF book you'll find this a great addenum. This book deserves a place next to books like Writing Solid Code and Code Complete.
I'm embarrased to see slashdot giving this book such a poor review. The book deserves all the praise and I strongly suspect that the reviewer never tried applying desing patterns. Pattern Hatching shows you how it all fits together. It doesn't discuss individual patterns but brilliantly shows you how they all interact. Buy it!
I've read design patterns and agree that it is one of the most useful books I've ever read (right up there with books by Scott Meyers, Sedgewick and Bjarne Stousstrup)...Click on the Amazon link to read several comprehensive user reviews of the book just in case the link above seemed rather dry to you.
PS: Please do not buy this book on Amazon. Go to Addall and find a vendor. Please keep up the boycott...thank you.
Why does the "ThinkGeek" link point to http://slashdot.org????????
"It's tough to be bilingual when you get hit in the head."
I found the reviewer's bias toward languages with built-in garbage collection a little annoying. For some projects it's appropriate to use a language with garbage collection (web scripts), and sometimes it's not (operating systems). While he may be "amused" by the need for manual deallocation of memory, he should understand that it's generally far more efficient.
Unfortunately, I think the reviewer doesn't have much experience with low-level system programming to understand these trade-offs. Until he does, he should resist making judgements.
P.S. This is not to defend C++ as a language...
--
I should look in the current SlashCode and fix something myself. Sometimes there isn't time for all trivial reported problems to be fixed.
Even worse is the "standard template library". That has become a playground for language fanatics. People are trying to implement LISP lambda-expressions using C++ templates, which is an example of using the wrong tool to implement a mediocre idea. The STL has resulted in a number of programming paradigms that are very complicated, bug-prone, and involve coordination of items far apart in the source text.
"Patterns" are being promoted as an answer to some of these problems. Just follow the ritual, avoid the taboos, and it will work. Don't try to understand why.
Anyone remember how the Symbolics LISP gurus messed up Common LISP, by insisting that all the crap their specialized hardware could support should go into the language and libraries? The STL crowd is doing that to C++. It's not good.
Humor item of the day: The Symbolics machines had the "MIT Space Cadet" keyboard, with a SHIFT key, a CNTL key, a TOP key, a META key, a SUPER key, and a HYPER key, all used as shift keys and all usable together. This came from a joke attempt at MIT to outdo Stanford, where the SAIL machine had TOP and META. Symbolics shipped that keyboard standard to customers. Symbolics is out of business.
I'll let you try and work that one out for yourself.