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????