Okay, here's the zeroth draft of a review. Comments, questions,
spelling flames are all appreciated.
=head1 NAME
Smalltalk Best Practice Patterns, by Kent Beck
=head1 SYNOPSIS
I<Smalltalk Best Practice Patterns> is not just for Smalltalk
programmers, it's the best book about Design Patterns I've ever read,
and hopefully the model for more.
=head1 DESCRIPTION
Some time ago now I read I<How Buildings Learn> by Stewart Brand; a
fine book, later made into a BBC TV series by some enlightened
producer in the days before dumbing down. Brand had lots of
interesting things to say about what he thought made good buildings
good and bad buildings bad, and what we as users, owners and
builders could do about it. In that book, Brand gave a great deal of
weight to the work of an architect called Christopher Alexander, who
had developed a new way of looking at what makes a good building good
and who had come up with a set of tools (A Pattern Language) which
could, he claimed be used to build good homes, workplaces, towns,
cities, countries, planets.
So, I toddled off to Amazon and picked up copies of I<The Timeless Way
of Building> and I<A Pattern Language> and read them, avidly. They
were, and are, wonderful books, full of practical advice and thought
provoking argument. In Alexander's view, a Pattern Language is neither
use nor bloody ornament if you (a layman) can't I<use> it to generate
buildings that have 'the quality without a name' or 'life'. His
Pattern Language is arranged hierarchically (well, sort of, its
flattened for publication in book form; imagine how a heap data
structure gets flattened into an array and you're almost there...),
and the individual patterns refer/feed back and forth to their related
'super' and 'sub' patterns (think of Cohen and Stewart's 'complicity
and simplexity' if you've read their work).
The idea is that a user of a Pattern Language would start at a
particular pattern appropriate to she wanted to build (say, a house
for a family). That pattern refers back to a couple of larger
patterns before explaining the problems that the pattern sets out to
solve, discussing the trade offs that need to be made and then setting
out a concrete set of recommendations to solve the problem. These
recommendations usually refer forward to smaller patterns, which refer
forward to further smaller patterns until you end up with
straightforward advice like 'break your windows up into lots of small
panes', 'build thick walls', or 'put bedrooms at the eastern end of
the house'. By controlling the interplay of these patterns and taking
account of local factors, the user can build a 'living'
building. (Alexander also makes plain that this should be an ongoing
process throughout the build of the house, constant feedback informing
and mutating the design (sound familiar all you XP converts?))
The only catch is, as Richard P Gabriel points out in I<Patterns of
Software>, Alexander's pattern language failed to achieve its
goals. In the hands of a great architect and builder, it could be (and
has been) used to produce beautiful buildings, but in experiments
where non architects used the language, they failed to produce
buildings that had the 'life' Alexander was aiming for. Alexander is
working on a 'patch' for this, and is expected to publish some new
work in this area in the near future (and I have a gut feeling about
what some of the changes are going to be, but no matter).
A few years later, I came across the concept of the 'Design Pattern';
a conscious appropriation of Alexander's pattern language ideas by
members of the Object Oriented Programming community. The canonical
book on the subject being I<Design Patterns> by the Gang of Four, and a
jolly good book it is too. So far as it goes.
The problem I have with I<Design Patterns> is that it lacks the
diversity of scale that one finds in Alexander's pattern language
which runs from pattern 1. 'A World Government', through to 'build in
low density concrete' (or some such pattern; I'm writing this on the
train and I've lent my copy of I<A Pattern Language> to someone else
anyway). The patterns that are there are very good indeed, and they
are well tied together, but there's an awful lot of gaps, especially
at the 'small' end of the scale.
Which is where Kent Beck's I<Smalltalk Best Practice Patterns> steps
up to the plate and hits an immediate home run. I<Best Practice
Patterns> is far and away the best book I have ever read on Design
Patterns. Ignore the fact that it's dealing specifically with
Smalltalk, read it for the I<ideas>. Beck is specifically dealing with
the 'tactics' of programming -- patterns in the small. His overarching
concern is to help you write code that is easy to understand, maintain
& extend. If you read nothing else, read the introduction in which the
author sets out his priorities and then clearly explains why.
If there's one word that sums up the patterns that follow it's
clarity. Beck explains the problem straightforwardly, gives concrete
examples and then offers a no nonsense solution. His patterns play
well with each other, and the satisfying 'feedback' that is such a
feature of Alexandrian patterns is evident here too. Beck is also very
good on what I'll call 'appropriate scale'; if you follow his
directions you'll end up with a collection of classes and methods
which are 'straightforward'; if a method is 'about' a house then it's
not going to get all tied up considering bricks, instead it'll let its
walls worry about them. Hmm... I'm not sure that's a useful analogy,
but I'll let it stand for now.
I don't program in Smalltalk, in fact I know very few people who
do. In some circles it's considered a dead language. I'm a Perl
programmer and (don't laugh) Perl's Object Oriented features have a
good deal in common with Smalltalk. Both languages are highly dynamic
-- there's no compile time type checking here -- and many of Beck's
patterns take advantage of that dynamism (and many more don't; this is
still worth reading if you're a Java programmer). There's a whole
section on patterns for using Smalltalk collections which are
of no immediate use to me (though it does make me want to implement
something like Smalltalk's Collection classes in Perl; but
that's another story).
In short, no matter what language you program in, so long as you do
OO, you'll take something useful away from this book. It is distilled
wisdom; easy to read, easy to digest, but deep and thoughtful too.
=head1 COPYRIGHT
Copyright 2002, Piers Cawley <[EMAIL PROTECTED]>
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
