"Pattern Hatching"
Marcel Weiher
marcel at metaobject.com
Sun Dec 1 09:52:39 UTC 2002
Hi Richard!
On Wednesday, November 27, 2002, at 04:25 Uhr, Richard A. O'Keefe
wrote:
>
> I've just been reading the book "Pattern Hatching: Design Patterns
> Applied"
> by John Vlissides, Addison-Wesley 1998, ISBN 0-201-43293-5.
>
> I have come away from this with two overwhelming impressions:
>
> (1) Here is a better than competent OO programmer,
> and C++ is fighting him every inch of the way
Well, that's C++ for you ;-)
> Example after example is basically "how do I design-hack a way
> around such-and-such a limitation of C++."
That's the impression the GoF book made on me.
> I've always been fairly positive about patterns, and I've taught
> them to students. This book, by one of the GoF, made me wonder.
> The examples strike me as Heath Robinson-ish; is this because of
> pattern-think, or is it because of C++?
Both!
> It would be really illuminating to see some of his examples
> revisited by a better than competent Smalltalker, because I
> think you'd end up with a completely different set of patterns
> being applied, or the patterns would look different
You get fewer patterns, but still too many.
> (2) One of the chapters describes the "GENERATION GAP" pattern.
> The example is a visual interface builder, where you draw your
> interface and the tool then generates code. "Normally, you
> can't create a finished, nontrivial application automatically
> with one of these tools; you have to implement some functionality
> the old-fashioned way, by hand in a programming language."
> So GENERATION GAP helps you by doubling the number of classes.
> (Er, really.)
>
> But WHY do you have to develop part of the interface in one
> environment (the interface builder) and the rest in another
> environment? Why shouldn't "what to do when you are pressed"
> be something you can plug in *and test* in the interface builder?
>
> The answer appears to be "because the interface builder is
> generating C++" (see point 1 above) "and can't itself run the
> code it generates".
Well, and because it is generating code in the first place. Interface
Builder (NeXT/Apple) doesn't generate code, it creates (and archives)
connected object graphs. Code generation is Evil.
> POOF! An entire pattern disappears up its own fundament if your
> environment can represent code as data and can run dynamically
> generated code.
Yes! IMHO, ALL patterns are like this. Think of it: why should there
be repeating patterns of code in our programs? There shouldn't be! If
there is a "pattern", we should be able to somehow express the pattern
and encapsulate it. "Once and Only Once".
So I consider a pattern a bug. Not a bug in the program, but a bug in
the programming language. Or let's call it a shortcoming, because the
language cannot encode this pattern in a way that I can put it in a
library and forget about it. I think the fact that many patterns
necessary in a primitive language ( C++, Java ) are not necessary for
their more advanced predecessor (Smalltalk) supports this point of
view. However, we shouldn't be too smug: the Smalltalk Pattern
Companion is not empty. In an ideal world / programming language,
there would be no patterns books.
There is some reason to believe that such an ideal world may be even
theoretically impossible, or at least impractical, but that doesn't
mean we shouldn't treat patterns as indicators of something being wrong.
Marcel
--
Marcel Weiher Metaobject Software Technologies
marcel at metaobject.com www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
More information about the Squeak-dev
mailing list
|