"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