TITLE: Thoughts on How to Design
AUTHOR: Eugene Wallingford
DATE: February 19, 2010 4:33 PM
DESC:
-----
BODY:
Smalltalk Best Practice Patterns is one of my
favorite programming books. In it, Kent Beck records
some of the design and implementation patterns that
he has observed in Smalltalk systems over the years.
What makes the book most valuable, though, is that
most of its patterns apply beyond Smalltalk, to other
object-oriented programming languages and even to
non-OO languages. That's because it is really about
how we think about and design our programs.
Kent's latest design endeavor is what he calls the
Responsive Design Project, and he reports some of this
thinking so far in a
recent blog entry.
The entry includes a number of short patterns of design.
These are not patterns that show up in designs,
but patterns of thinking that help give rise to designs.
Being hip deep in teaching functional design style to
students whose experience is imperative programming,
many of Kent's lessons hit home for me.
Inside or Outside. Change the interface or the
implementation but not both at the same time.
This is a classic that bears repeating. It's tempting
to start making big changes to even a small piece of
code, but whenever we conflate changes to interface and
implementation, we risk creating more complexity than
our small brains can manage.
Isolate Changes. Before making a change, isolate
the area to be changed from the rest of the system so
you can change an entire element at a time. For
example, before changing a part of a procedure, extract
the area to be changed into its own procedure. Make the
change, then inline the changed sub-procedure if
appropriate.
This one is beyond the ken of most intermediate-level
students, so it doesn't show up in my courses often.
When we confine a change to a small box, we control the
complexity of the change and the range of its effect.
This technique can even be used to control software
evolution at a
higher level.
Exploit Symmetries. Divide similar elements into
identical parts and different parts.
Many beginning programmers find it counter-intuitive that
the best way to eliminate duplicated code is to increase
the level of duplication, maximizing the repetition to
the point that it can be factored out in the cleanest and
sharpest way. I have come to know this pattern well but
sense that its value runs much deeper than the uses to
which I've put it thus far.
Then there is the seemingly contradictory pair
Cultivate Confidence. Master your tools. Your
feeling of mastery will improve your cognition.
and
Cultivate Humility. Try tools or techniques you
aren't comfortable with. Being aware of your limitations
will improve your effectiveness.
Of course, the practices themselves aren't contradictory
at all, though the notion that one can be confident and
humble at the same time might seem to be. But even that
holds no contradiction, because it's all about the edge
between mastery and learning. I often talk about these
patterns in my programming classes, if only hope that a
student who is already starting to sense the tension
between hubris and humility will know that it's okay to
walk the line.
Finally, my nominee for best new pattern name:
Both. Faced with design alternatives without a
clear winner, do it every way. Just coding each
alternative for an hour is more productive than arguing
for days about which is better in theory, and a lot more
satisfying.
You may have heard the adage, "Listen to your code",
which is often attributed to Kent or to Ward Cunningham.
This pattern goes one step beyond. Create the code that
can tell you what you need to hear. Time spent talking
about what code might do is often much less productive
than simply writing the code and finding out directly.
Early in his essay, Kent expresses the lesson that
summarizes much of what follows as
Our illusion of control over software design is a
dangerous conceit best abandoned.
He says this lesson "disturbs and excites me". I guess
I'm not too disturbed by this notion, because feeling
out of control when working in a new domain or style or
language has become routine for me. I often feel as if
I'm stumbling around in the dark while a program grows
into just what it needs to be, and then I see it.
Then I feel like I'm in control. I knew where
I was going all the time.
In my role as a teacher, this pattern holds great danger.
It is easy after the fact to walk into a classroom and
expound at length about a design or a program as if I
understood it all along. Students sometimes think that
they should feel in control all the time, too, and when
they don't they become discouraged or scared. But the
controlled re-telling of the story is a sham; I was
no more in control while writing my program than they
will be when they write theirs.
What excites me most about this pattern is that it lifts
a burden from our backs that we usually didn't know we
were carrying. Once we get it, we are able to move on
to the real business of writing and learning, confident
in the knowledge that we'll feel out of control much
of the time.
-----