Patterns and Compositionality
Fri, 28 Jan 2000 19:23:35 +0100
Jim Little wrote:
> This is exactly the point I was trying to address in my original post:
> Massimo Dentico wrote:
> > *if* the substitution process (generalizing/inlining) for
> > patterns in OOD is equivalent to the substituition process in
> > functional/logic languages (pattern matching) [...]
> It is not equivalent.
> Design patterns in OOD are not substituted, generalized, or inlined.
> The concept has no meaning for design patterns. Design patterns are a
> way of communicating knowledge. They're written in natural language for
> use by human observers. To use a design pattern, you read it,
> internalize it, and intuit its applicability to your design. Good
> design is a matter of communication and understanding, not
> functionality, and as such it simply can't be formalized or automated.
> As a tool for communicating "good design," neither can design patterns.
> Comparing design patterns to pattern matching in functional languages is
> a fallacy. They are not comparable.
> PS: I'm not trying to address the rest of the discussion -- I'm just
> trying to clear up a pretty strong misunderstanding about the nature of
> design patterns.
Your point is extremely clear to me, even before this
clarification. I insist: if you (or the inventor) give a vague
definition of a concept, even if I present to you a more rigorous
one, asserting that it catchs all or the substantial part of the
concept, then you can always present an example that invalidate my
However, Bill Tanskley, and not I, has written exactly this in the
thread "Refactoring in Tunes", 2000/1/9:
> [snipped: example of finding redundant *patterns*, making them
> into a function, and calling the function from both places]
> No, that's function factoring, not Refactoring. My "Refactoring"
> book calls that "Extract Method". Refactoring also includes the
> inverse of that -- "Inline Method". A good coder should know how
> to do both refactorings; sometimes you need to inline a method
> in order to get special behavior (or because you made a poor
> choice of factoring earlier and now you have to redivide your
> functions' functionality).
For what I remember about the subject (and I admit a superficial
knowledge) Bill is not wrong, this exemplifies one of the intended
meanings of the word "pattern". I heard also "pattern instance"
and "pattern abstraction" or something similar. The matter is too
vague to exclude these uses. I have an hypertext excerpt from the
book "Object Models: Strategies, Patterns, and Applications", by
Peter Coad, with David North and Mark Mayfield, Prentice Hall,
1995. ISBN 0-13-108614-6. It defines a pattern in this way:
pattern (for object models)
A pattern is a template of objects with stereotypical
responsibilities and interactions; the template may be applied
again and again, by analogy. Pattern instances are building
blocks, very helpful in building effective object models. Patterns
are categorized into these pattern families:
- fundamental pattern
- transaction patterns
- aggregate patterns
- plan patterns
- interaction patterns.
This is an attempt to define a little more rigorously the concept
of pattern, it restricts the attention to "object model" that Coad
uses also in his book about design, "OOD" with Yourdon.
Now, I have few doubts that the formal concept of substitution, or
pattern matching, catchs the process of generalizing (abstracting,
extracting)/using (inlining) a "pattern" like this defined above.