"Pattern Hatching"
Richard A. O'Keefe
ok at cs.otago.ac.nz
Wed Nov 27 03:25:01 UTC 2002
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.
Example after example is basically "how do I design-hack a way
around such-and-such a limitation of C++."
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++?
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.
(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".
POOF! An entire pattern disappears up its own fundament if your
environment can represent code as data and can run dynamically
generated code.
I just wish I understood Morphic better.
Smalltalk: back to the future????
More information about the Squeak-dev
mailing list
|