General talk about software patterns

["Ralph Johnson" <johnson AT cs.uiuc.edu>]

On 5/23/06, Al Boldi 
<a1426z AT gawab.com>
 wrote:
> A pattern is the abstraction of a context problem to yield a general
> solution.

If you look in a dictionary, you will see that there are two general
meaning of "pattern".  One is something that is copied, perhaps
something that is worthy of emulation.  The other is a repetition,
i.e. it is as if pattern has been copied even though we know it
hasn't, like the patterns of waves on the beach.

A pattern in software is both of these.  It starts out as a phenomenon
that we observe, and we decide that we like it and want to promote it,
so we write it down and suggest that people copy it.

I do not think that Alexander's statement that "a pattern is solution
to a problem in a context" was a definition, rather it was a
characterization.  Why is something a pattern?  Why do we see this
technique so often?  Why does the old pro tell the newbie "let me show
you how it is done"?  It is because there is some problem that recurs,
and the pattern is a solution to that problem.  To understand the
pattern, you must understand more than just the solution, you also
need to understand the problem.  And there are probably other
solutions to the problem, so to understand when the pattern is best,
you need to understand the context.

To me, a pattern is something you have seen before.  It is something
you expect to see again.  Even if you don't know what problem it
solves, or even exactly how it works, you can tell it is a pattern.
The hard part is not noticing patterns, it is understanding them.  It
is hard to define the problem that a pattern solves.  It is hard to
make it abstract enough that it will be widely applicable, but
concrete enough that it makes sense.  So, noticing that something is a
pattern is just a start.

-Ralph Johnson