TITLE: using design patterns - a rationale

(Newsgroups: comp.lang.smalltalk,comp.lang.c++,comp.object)

SMITH: Dave Smith <daves@terracom.net>, Mon Aug 12

>I thought Alexander was an architect. What that has to do with 
>computer science beats me.

JOHNSON:

Alexander wrote about design of buildings and communities.  He is
interested in the human side of why they are the way they are.  Most
computer folks who read his books see all sorts of things that are
similar to software.  This is because (in my opinion) design is
universal, and so there is a lot that building design and software
design have in common.

I've found lots of software people (even before software patterns became
popular) who got excited when they read Alexander.  "Alexander is right on!
We should do something like that for software!"  But when you dig deeper,
you find that different people get excited about different aspects of
what Alexander said.  It is pretty hard to apply his work directly to
software.  The thing that had the biggest impact on me was his
observation that the reason there are repeating solutions is because
there are repeating problems, and you don't understand a pattern until
you understand the problem that it solves and the forces that it 
resolves. I also liked his insistence on getting patterns by looking
at things that have been built and that have withstood the test of time.
Other people get turned on by "The Quality Without a Name", or his zen
allusions.  He makes a good inspiration, but not necessarily a good guide,
because he leads in different directions for different people.

SMITH:

>In a very long thread elsewhere with a major pattern guy, I was told patterns 
>are 1) a methodology; 2) a complete pedagogy; 3) a heuristic; 
>4) a thing to take on faith.

JOHNSON:

These are uses of patterns, not what they are.  At the moment, none
of the sets of patterns are complete enough to use as a methodology
or a complete pedagogy, though there are certainly people who would
like them to be.  Lots of people think that if we can just get all
the patterns that we know written down, we'll have a complete methodology.
I'm skeptical.  I use them for teaching, but I do not think they will
form a complete pedagogy.  They *inform* my pedagogy, in that I can
organize what I teach around the patterns I want to get across, but
I can't just start plopping patterns down in front of students.  They
don't understand a pattern until they have a need for it, so I have to
set up problems that need a certain pattern before I can teach that
pattern. I bet the same is true of using it as a methodology.

I've noticed that a lot of people interested in patterns do not
like the standard methodologies.  I think that is why many of
them are hoping that patterns will succeed where (they claim)
methodologies have failed.  We'll see.

Patterns can obviously be used as heuristics.  They are actually
stronger than that, since a pattern is supposed to explain why it
solves the problem, so it is part of your design rationale.  And
they can certainly be taken on faith, which is what usually happens
when you hire a consultant and he says "do it this way".   :-)

SMITH:

>I'm fine with design patterns as ethos, i.e., someone says "this is how I do it, this 
>is what works for me, my personal credo." My problems start when "design patterns" 
>become a methos, not a programmer belief but a programming methodology. 

JOHNSON:

But are't all programming methodologies programmer beliefs?  It seems to
me that a belief becomes a methodology when it becomes written down and
people start to be trained in how to use it.  But most of our methodologies
started out as somebody's belief in how to build things.  That is why they
are called "Booch's method" or "The Coad/Yourdon method".

The great thing about patterns is that you aren't supposed to just write
down the problem and the solution, but you are supposed to give a
justification.  Thus, when you read somebody else's pattern, you are
more likely to be able to argue with him if you don't like it.

And you *are* supposed to argue!  A pattern is supposed to explain
why things are the way they are.  It starts with some phenomenon
you notice, and then develops into an explanation of the
phenomenon.  The assumption is that there is probably a good
reason for things being this way. It is hard to write good patterns.
They usually evolve over time as the author gets feedback from
people and learns how to define the problem and to describe the
variatios on the solution.

Dave then described a pattern someone had told him, and argued why
it was a bad pattern, that it wouldn't be necessary if designers
just made sure they picked their abstractions and their names from
the real world.  Dave was asserting a new pattern "Real World Names".
Now, I could harumph that this is a well-known pattern that any
half-decent OO programmer knows, and the pattern author that he was
talking to would have known it, so Dave must have misunderstood him.
But patterns are literature, they are documentation.  It is always the
job of an author to make sure his audience understands him.  If Dave
misunderstood this author, it was the author's fault, not Dave's.  The
author needs to change his pattern.

Of course, maybe there is a real disagreement.  Maybe Dave is right
and the author is wrong.  Or Dave is wrong and the author is right.
Or they are both wrong.  They can't both be right.  If they are both
right, but just under different situations, the author should have
described that situation better when he was describing the context
of his pattern.  The burden of proof is on him.

-Ralph Johnson