General talk about software patterns

[Al Boldi <a1426z AT gawab.com>]

Ralph Johnson wrote:
> 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.

Would this be in contrast to the GoF definition, that "a pattern shouldn't be 
called one, until there have been at least three independent implementations 
of it" as Simon has mentioned?

> 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.

So, if I read you correctly, for a pattern to be useful, the abstraction 
phase has to be successful.  So really, the question should be:

        What are the ingredients of a successful abstraction?

Your comments and directions are much appreciated!

Thanks!

--
Al