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!
10010110110100101110110100100111001101001
Looks suprisingly like...
1001010110110001011010111011011010001001
I found a hole a while back that would allow you to post images via the poll.pl script. They fixed that, and the url in my post didn't work anymore (because /. stripped the encoded HTML from it automatically). Probably the same thing happened to you.
I didn't get -5'ed though - infact, I think I ended up +1 (after a huge moderation war). I've never seen -5 before.
BTW, there is still a hole that lets you post images - not on the story, though. That was a cool hack.
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...
--
there, I flamed you
the moderator was right to mark it flamebait
if he/she hadn't, I would not have flamed you
it's not my fault!
blame the mods!
I should look in the current SlashCode and fix something myself. Sometimes there isn't time for all trivial reported problems to be fixed.
It does not matter how much effort goes into something like this, there will be no substitute for thought. This, like much of the OO philosophy, are (in my view anyway) attepmts to reduce thinking to something you can do mechanically. Just follow the right instructions, and youll write great programs.
Mind you, Im not saying that this is all bad. It might help some people sometimes, but most of the time stuff like this just takes space in peoples brains and gets in the way of reasoning. Instead of following their own thoughts, they try to remember and to live up to the wise sayings of GodFather(tm) Suchandsuch... and invariably get it all wrong.
Besides, I think it is a questionable practice to face a problem with a "in what pattern would it fit" attitude.
My view, anyway,
rmstar
I have this book. I haven't read it cover to cover (yet), but have absorbed sections as appropriate.
I like it. It seems down to earth. I agree that occasionally, the examples seem a wee bit forced, but I'm not bothered by the C++ focus as that is my preferred language.
I'd agree that the book is a good read if you are into patterns. If you aren't, you should check out the patterns web site, and the original Design Patterns book.
Also, I went nuts and bought the original Christopher Alexander architectural patterns books. They look fantastic!
--
--
Marc A. Lepage
Software Developer
Seems that much the same things were said about "goto", quite a few years ago: It's bad, many times you should not use it, definitely not without understanding the consequences, use only in certain controlled situations...
Well, okay, but personally I think that applies to just about any programming construct. Use it where it belongs, don't use it if it doesn't belong.
The review appears to fall into the trap of He wrote a book, but it wasn't what I would have written, so lots of it must be wrong. No, I don't think so.
The Autonomous Cow. Moo.
At the risk of descending into techie wibble, I'd take issue with a couple of the reviewer's comments.
First, Singleton is _not_ just a misguided substitute for globals. It's an answer to the so-called "static initialization order fiasco" - the compiler doesn't guarantee that globals in different obj files are constructed in any particular order, so if the constructor for one such global requires that another one already be initialized, you either take your chances or you adopt an initialize-on-first-use idiom, i.e. Singleton. It isn't necessarily good enough to say "but there aren't any dependencies"; there might be in the future, and this is a sufficiently subtle problem that the designer should be considering it from the start.
Second, I wouldn't agree that "delete this" is primarily bad because it screws up objects on the heap. If you're using it, your class shouldn't allow heap allocation. The main problem is that it invalidates a pointer in the caller's scope without giving the caller any clue that this has happened.
Rant over. It is a good book; take a look.
If you are interested in Human Computer Interaction and Object Oriented Techniques (like I am :) ) take a look at uidesign.net. There is section about patterns for UI.
--Ivan, weenie NT4 user: bite me!
--weenie NT4 user: bite me!
"Computers are nothing but a perfect illusion of order" -- Iggy Pop
And who should not be developing patterns? (or who might read the book, but not those chapters?)
Anyone who designs or codes programs finds himself continually seeking solutions to different problems. Each solution represents a pattern of solutions to similar problems, so either the designer/coder is using existing patterns or he is inventing new (or at least undocumented) ones. So I think every designer/coder is using and/or creating patterns. Consequently every designer/coder who wants to improve his work should seek to improve his use/creation of patterns, and could benefit from all of the book.
Just my $2e-2.
The Autonomous Cow. Moo.
That is a scary thought. One doesn't "write" a pattern. A pattern documents a clean proven solution. The thought of bozos jumping in and "writing" patterns is a horror beyond belief. A valid pattern must offer wisdom and insight. One discovers patterns; one documents patterns; one does not "write" patterns.
... when I smoke your skanky crack.... oh wow...
WTF is your point, grease stain? Trolls get in the way of advancing the discussion. Collective work takes time and looks messy when unfinished. (Look up "work", if you don't recognize the term.) Moderation's a great, gentle, freedom-loving solution to the disruptions of juveniles; it even preserves that kind of output should anyone care about it (yeah, that'll happen). Back under your bridge.Is poor Bo Gritz down hot Porter Lee Nadman's pants?
The concerns about 'delete this' are certainly understandable, but generally unfounded. In well-behaved code, an object will not delete itself unless all clients have released their references to it, just as in a garbage-collected environment. Certainly a pointer to the object may reside on the stack, but there's no harm done in passing or manipulating a pointer value with nothing attached to it. As long as nobody uses the original object anymore, there's not a problem.
The memory management issues under C++ are certainly heinous, I agree. C++ with garbage collection would likely prove to be the most useful OO language around...but Java's getting close to that anyway. Following certain rules for memory allocation and deallocation in C++ can usually iron out the troubles.
Good review. It's refreshing to see a reviewer that has a broad enough education to be familiar with languages other than the standard grab bag of C, C++. As the reviewer points out, the language makes a big difference in design patterns. C++ makes a lot of things difficult. A lot of the standard design pattern are easier or trivial in a more expressive/well-thought-out language. Peter Norwig states: "Study of the Design Patterns book: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern" See http://www.norvig.com/design-patterns/
Here are a few replies to comments posted to my review. Some of these comments I expected; some took me by surprise.
1. I strongly suspect that the reviewer never tried applying desing patterns, and I think the reviewer doesn't have much experience with low-level system programming:
I won't list my whole professional career here. You can find selected parts here. I'm not trying to boast; Slashdot would be the silliest place to do that, since I realize a great many of the readers had much more impressive careers than mine. But suffice to say that in my 14+ years as a programmer, I have programmed in C++ for well over 6 years. (You can find some of my C++ work in IBM's AlphaWorks site, for example). Is that experience enough for you? I also have some good experience with low-level systems programming (just for the record, I currently teach the OS Structure course in the Technion -- the "Israeli MIT"). I realize when and where manual deallocation is important -- but what most people seem not to realize is that in most cases, it isn't. Plain in simple: in most projects, it is better to leave the deallocation to the machine (see Meyer's OOSC2 for detailed arguments on this, better than anything I could present here).
As for working with patterns: The GoF book was published in '94. I stumbled upon it purely by mistake; and I was actively using patterns in my work by early '95. Further, part of my work was (and still is) design consultancy for large OO projects. Let's just say that I know a pattern when I see one; I know the need for a pattern when I see one; and I also know when a pattern is misused.
2. Singleton is _not_ just a misguided substitute for globals:
I know it isn't. What I meant to say is, in many cases, people use Singleton as a replacement for globals. Which is a bad design. I've seen too many cases where people thought that, rather than moving references around, they're better off creating a Singleton class, practically making the object a global that anyone may access. Of course this is not what Singletons are for; but this use does occur. Sorry if I wasn't clear enough on this point.
3. I found the reviewer's bias toward languages with built-in garbage collection a little annoying:
All "the reviewer" meant to say was that he found the book's bias towards langauges without GC a little annoying; especially in contrast with the original Design Patterns book, which had no such bias.
4. (Regarding delete this): If you're using it, your class shouldn't allow heap allocation:
Of course. But in Real Life(TM), it happens that one person writes a class (without stack allocation), and another modifies it -- not being aware of the "delete this" statement deep inside the class, he could add that feature. Or it could be added in a subclass, by someone who does not have access to the source of the original class and does not know it uses "delete this". And so on. Sure, you should comment your code well enough to prevent such unhappy accidents; but they will still happen. Trust me, I've seen them happen...
Maybe this is not the best source for code examples, but one commercial project where I've seen "delete this" used in a class, and a sub-class allowing stack allocation was... MFC (a rather old version, from mid-'95. It might have been changed since then; I haven't used MFC recently so I'm not up-to-date on the issue).
5. And who should not be developing patterns?:
Very good point. So perhaps I didn't make myself clear enough on this issue: the chapters are intended for those who mean to publish the patterns they come up with during their work. How to present it, how to document it, and so on. You'll agree that this is a much smaller crowd then all pattern-users in general.
-------
That's all, folks. I'll be happy to reply to any additional comments. While I didn't rank the book a perfect 10 (because it simply isn't a perfect book), I still think it is a good book, and I do recommend it for serious programmers.
- Tal Cohen
Don't just take my word for it, go check out Design Patterns in Dynamic Programming in which Peter Norvig shows that 16 of 23 patterns in the canonical Design Patterns book are unnecessary or much simpler in Common Lisp due to the availability of multiple dispatch, first-class types, and real macros.
To a Lisp hacker, XML is S-expressions in drag.
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.
Sometimes I wonder if real purpose of patterns nowdays is to make money by writing books about patterns and particularly _about_ patterns (not introducing new patterns itself, just telling how great patterns are in general). GoF is great book and it have helped me a lot with OO-designs, but when you read Pattern Languages of Program Design -series, you mostly find abstract academic nonsense and babbling without any examples or real help to your own problems (sure there's exception, for example in volume 3 there's great pattern for serialization). I think that same thing applies mostly to Pattern Hatching.
All this weird pathetic bureaucratic gobbledygook surely must interfere with one's ability to just fucking GET THE JOB DONE.
That's why it takes 50 lines of C to code a fucking "Hello World" window. Any less and you might fuck up the widgets, or worse, the garbage collection scheme or something.
That's why I like scripting languages like php and perl. I spend more time working on higher level things like implementing my imagination and tweaking it, than bogging myself down in endless centuries of debugging Crap++.
Mark my words, as complex as Crap and Crap++ are now, it's going to get even worse in the future. You're going to need 1500 lines for a simple "Hello World" app as GL becomes a big hit.
Anyone ever see how much code is in a Linux kernel now? Fuck. What a messed up industry this is gonna be. One day we'll all be like those programmers in Snow Crash who can't possibly write a whole application, but rather, they have to write tiny modules.
What you're missing is that the phenomenon you're referring to is simply a maturing of the software engineering discipline. EVERY engineering discipline has gone through this. Look at typical hi-tech consumer products today. You have cell phones and PDAs, devices that take tens or hundreds of people to design and build. A few hundred years ago, watchmaking was probably considered hi-tech and could be done by one person. The wright brothers built an airplane, but now you have thousands of people working on space shuttles and you have to deal with safety standards, and other "bureaucratic gobbledygook" and there's no way one person can do the job. Software engineering is still a very young industry, which is just beginning to mature. In 20 years, I think you'll be wondering how we ever managed to produce large-scale software at all in the 20th century with such primitive processes.
The GoF and their associates were busy implementing patterns for years before they wrote the book (ET++, InterViews, Unidraw, etc.) Most people have not been able to gain pattern knowledge from those implementations, unless they were engaged in actual programming, application, reuse, extension and evolution of the code, willing to study Vlissides' thesis, and so on. The books are an attempt to explain the ideas in a semi language and implementation independent way. It's only natural that that kind of presentation would draw in the talkers, but the ideas should resonate strongly with doers. Their doer background is what gives credibility to the GoF and distinguishes them from the average design fanatics. If you haven't examined the GoF's implementations before they wrote the book you are missing a big part of the story.
I don't know what you're talking about with all this static initialization whatchamacalit. My compiler has no such limitations. Oh, I see, you are talking only about C++. Well, you should have said so :-).
[I agree that the reviewer is off his rocker about delete this, though.]
A couple of weeks ago John Vlissides took part in a debate at the POPL conference in Boston (Principles of Programming Languages), and although the academic community favours functional languages and is thus biased, a strong view was expressed that design patterns are prompted by the lack of appropriate language features (tools). /., I would be interested to hear arguments for straight C, i.e. procedural progamming.
Alternatively, you could view it as "getting round" the disadvantages of object oriented programming paradigm.
Although I do not expect there to be any functional programmers around on
Thanks
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
--
Whether you think that you can, or that you can't, you are usually right.
****Gfx Scrollbar Special case hit!!*****
I'll let you try and work that one out for yourself.