I found Design Patterns in the library while
looking for a Haskell book and had to read it,
because I had read so much about it.
It's quite a different sort of book than Damian
Conway's Object-Oriented Perl. I haven't actually
read that book, but judging from the downloadable
chapters, it's a nuts-and-bolts book. Perl
provides you some object-oriented jigsaw puzzle
pieces and Object-Oriented Perl helps you work
out which pieces fit together to get things done.
Design Patterns, on the other hand, is a top-down
kind of book. Its focus is on what sorts of
things get done in object-oriented programming,
and although there is C++ and Smalltalk code, I
think it is as an example. The book is not just
for users of those languages.
The impact of the book was because of this
super-language level, I think. It was
conceptualizing (naming and framing) design
structures which existed but hadn't been
recognized and which couldn't be captured in just
a discussion of language syntax.
The role of Christopher Alexander in the book is
interesting. He may have been inspirational, but
there is hardly anything in it that depends on
his ideas, I think.
If he read it, I think he would have felt
disappointed, because of the lack of real use of
his ideas. Peter Gabriel has written stuff which
puts Alexander's ideas to work better, I think.
Actually, I get the feeling that the esteem in
which Alexander's ideas are held is little
consolation to Alexander for his inability to get
architects to take him seriously.
A better metaphor than architecture is genre
analysis. It fits in with the language metaphor.
On the first page they use the analogy of plot
structure and OO design decisions.
The book is kind of repetitive. It looks like
they wrote parts separately, and then put them
together. The motivations for each pattern are
often repetitions of the discussion in the Lexi
case study, which seems not to be a real program,
but a made-up example.
I've been reading the book in the kitchen, rather
than in front of the computer, and although I'm
doing something with iterators at the moment, I
don't think the discussion of Iterator pattern is
going to have much effect on what I'm doing.
Perhaps I'll regret not reading more carefully
when the book is back in the library and I'm
struggling with code.
Actually, they do a good job of teaching. The
problem is that the real work is done by the
learner.
In their brief history of the writing of the
book, they say in the final year they put a
greater emphasis on the problem a pattern solves.
This was connected to the difficulty of learning
the patterns. The only ones who could understand
the patterns were the ones who already used them.
This is an important observation. I can't really
connect my problems with the problems they are
solving, so I am not going to learn their
solutions.
For more serious learners, perhaps end-of-chapter
exercises will not help very much. The only way
for learners to learn the patterns is to
conceptualize everything as a nail and try to hit
it on the head with a hammer.
Only when they get a better feeling for what is
and isn't a nail will they have really learned
the patterns. Until then, they are trying them
out.
This is the reason for the complaint by
experienced programmers about the rigidity of
people who have just read the book. They are
still learning.
This is a higher-level learning than the learning
of how to code the patterns, but connected to
this lower-level learning.
