(ref.doc)pd060395

Date: Mon, 6 Mar 1995 14:17:58 -0600
Originator: [email protected]
From: [email protected] (Doug Lea)
Subject: Proto FAQ for patterns-discussion

I noticed over the past week recurrences of some patterns of
discussion on this list. So I made some not-entirely-serious first
steps towards a patterns-discussion FAQ (NOT a patterns FAQ -- it does
not deal with any particular patterns). I scanned through old postings
and distilled topics and discussions down to short caricatures.  I
made a few token attempts to remove my own biases but surely many
remain.


Q: Why isn't there a good definition of `pattern'?
A: Why isn't there a good definition of most engineering terms?
   `Pattern' seems on at least as good footing as, say `object'. No
   one seems to mind the short slogan `a solution to a problem in a
   context'. 

Q: What's the best format for patterns?
A: Take your pick. Most of Alexander's patterns are of the form:
     IF   you find yourself in <context>
          for example <examples>,
          with <problem>,
          entailing <forces>
     THEN for some <reasons>,
          apply <design form and/or rule>
          to construct a solution
          leading to <new context> and <other patterns>
   There are many stylistic variants of this format.  Another format
   (often used by Ward Cunningham among others) is purely narrative.
   But the most popular style (used in the GOF book) mostly inverts
   this, starting out with the design forms and/or rules and then
   describing problems, contexts, and examples to which they apply.

Q: Can patterns take a negative form, telling you what NOT to do?
A: Perhaps ideally not -- sets of good patterns would steer you clear
   of the infinitely many bad designs you could come up with. But
   some ideas are so bad that they deserve explicit mention.

Q: Can patterns present a set of alternative solutions rather than one?
A: Perhaps ideally not -- each solution should be be tied to the
   context in which it best applies. But sometimes this is too hard.
   Mentioning alternatives is better than not mentioning them
   since it sets up scaffolding for further refinement.

Q: Can't you use a better word than `pattern' to describe these things?
A: You can call them anything you like, but its too late to change
   what most other people call them.

Q: What makes a pattern good?
A: While not emphasized or even addressed in some software patterns,
   Alexander's usage includes the idea that a pattern represented a
   kind of equilibrium of forces. (Even Alexander has been criticized
   (even by himself) for not always carrying this out in a convincing
   manner.) This is the same notion as optimality as seen for example
   in the analysis of algorithms in computer science, but applied to
   micro-architectures etc., rather than algorithms, and typically
   based on harder-to-measure force criteria (mostly 'ilities':
   extensibility, reusability, performance, reliability, complexity,
   etc). And sometimes a pattern is considered good because it is the
   only solution we even know, or because it has withstood a barrage
   of critiques. Another set of considerations revolves around
   stylistic issues -- whether a pattern is written in an
   understandable way. Try analyzing some real patterns so we can
   develop better evaluation guidelines.

Q: Can patterns be expressed in <some particular some formalism or notation>?
A: You are welcome to try, but bear in mind that a representation of a
   design or design rule in some formal notation is not a pattern if
   it omits descriptions of context, the problem(s) it solves,
   evidence for adequacy of the solution, construction or
   implementation guidelines, or relations with other patterns.

Q: What's the difference between a pattern and a framework?
A: A framework is not a pattern, but may have been built using
   patterns. Also, the use of the framework may be described via
   patterns.

Q: What's the difference between a set of patterns and a style guide?
A: While it might be possible to structure style guides as sets
   of patterns, none of them do. In particular, style guides
   typically omit descriptions about how to construct solutions.

Q: What's the difference between a pattern and a programming idiom?
A: A pattern can be used to describe how, when, and why to use an idiom.

Q: Can patterns describe standard OOP concepts like inheritance?
A: Sure; similar answer.

Q: Are patterns programming-language-independent?
A: Some (even most) are.

Q: What's the difference between a pattern and a data structure?
A: The designs described in some patterns might be thought of as 
   specialized data structures and related techniques.  So?

Q: Why bother writing patterns that just boil down to advice my 
   grandmother would give me?
A: Because some patterns are so good and useful that even your
   grandmother knows them. It doesn't hurt to write them down.   

Q: What's the difference between a pattern language and a set of patterns?
A: Arbitrarily little.

Q: What is the theoretical basis of Patterns?
A: No formal basis, athough patterns express design notions stemming
   from all sorts of theoretical and empirical bases.

Q: Are `requirements' patterns different than `analysis' patterns
   different then `design' patterns different than `programming'
   patterns?
A: This might be fun to discuss, but is too murky to answer definitively.

Q: Must all patterns be so low-level/high-level/general/specific/... as 
   <some pattern>?
A: Of course not.

Q: Is there a recommended development process associated with the use
   of patterns?
A: Probably so, but even though we discuss it a lot, we don't know
   what it is.  Use patterns so we can find out.

Q: Does the use of patterns have any effect on business practices 
   and software economics?
A: Same answer.

Q: Can software development process and organization be described 
   using patterns?
A: Sure, there are several examples. They tend to generate controversy.

Q: Can I use patterns within <some particular OO Analysis and Design method>?
A: Probably so, although if you do, you might no longer be following
   much of the method beyond its notation.

Q: Won't the existence of lots of patterns lead to problems in
   finding, indexing, using, and maintaining them?
A: Maybe. But there may be fewer good patterns waiting to be written
   than you think. Or maybe many more. Try writing some more patterns
   so we can find out.

Q: Can patterns be used as the basis of software design handbooks?
A: Yes, in fact, most interest and work in software patterns arose
   among people trying to figure out what should go in such handbooks.

Q: How would a patterns-based software design handbook different 
   from handbooks used in other kinds of engineering?
A: Among other differences, fewer tables of values of physical constants.

Q: Wouldn't it be nice to have some patterns-based CASE tools?
A: Could you clearly explain what you would like them to do?

Q: Why aren't there more patterns about <whatever>?
A: Because no one has written them.

Q: Wouldn't it be more useful to teach people to write patterns rather
   than teaching them to use a bunch of existing patterns?
A: Both are needed. Neither is more needed.

Q: Why aren't Alexander's patterns universally used by architects?
A: There seems to be no single reason but people cite factors
   including clashes with long-established practices and with the
   professional culture of architects, economic factors, the fact that
   Alexander focuses on having people design and build their own
   houses, and differences in opinion about how good or useful the
   particular patterns in A Pattern Language are in practice.

Q: Are patterns over-hyped?
A: Of course. 

Q: Do patterns really work?
A: Please ask a more specific question.