Michael Schuerig <firstname.lastname@example.org> wrote:
| > If they aren't patterns, then it's because they are *better* than
| > patterns (because they remove the need for many patterns).
| It seems to me that your conception of patterns is too narrowly tied to
| the catalog presented in Gamma et al.'s "Design Patterns". Jim Coplien
| is even collecting Organizational Patterns. In a sense, patterns are
| condensed expert knowledge.
Indeed. See Richard Gabriel's excellent rant in his book "Patterns of
Software" against the Gang-of-Four's freezing of Christopher Alexander's
notion of patterns into some rigid identification with class libraries.
Nothing could be further from the truth.
IMHO, a pattern is *any* recognizable meta-structure that provides useful
shape to the otherwise bewildering chaos of design space, e.g., Alexander's
"alcove pattern" in designing shared living spaces (an example discussed
at length in Gabriel's book).
| In Lisp, too, you have to decide to solve the problem in that particular
| way -- and that's the heart of the pattern.
To me, the heart of the whole "pattern" notion is that a pattern is *not*
a rigid template -- it has to be adapted to the "local conditions" of the
solution space of the problem being solved. And a given solution often
involves the use of more than one pattern, and each has to be adapted/
tweaked/bent/evolved/merged to fit harmoniously with the others, something
that is simply impossible with pre-defined libraries/classes/templates.
Rob Warnock, 8L-846 email@example.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA