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