Re: Patterns and Compositionality

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.
> 
> Jim
> 
> 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
rigorous definition.

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.

-- 
Massimo Dentico