Patterns-Discussion FAQ

Maintained by Doug Lea . Mail comments to

Last updated on Wed Mar 8 06:16:50 1995

This is not a FAQ in the usual sense. It contains very brief summaries of topics that have been discussed on the patterns-discussion list, in question and answer format. Choice and content of items reflect the biases of the maintainer. This FAQ is updated on an irregular basis.

For introductory information about patterns see The Patterns Home Page.

  1. Why isn't there a good definition of `pattern'?

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

  2. What's the best format for patterns?

    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 SOLUTION
              leading to NEW CONTEXT and OTHER PATTERNS

    There are many stylistic variants of this format, including the purely narrative Portland Form. But the most popular format (used in the Design Patterns book) inverts this, starting out with the design forms and/or rules and then describing problems, contexts, and examples to which they apply.

  3. Can patterns take a negative form, telling you what NOT to do?

    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.

  4. Can patterns present a set of alternative solutions rather than one?

    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.

  5. Can't you use a better word than `pattern' to describe these things?

    You can call them anything you like, but its too late to change what most other people call them.

  6. What makes a pattern good?

    While not emphasized or even addressed in some software patterns, Alexander's usage includes the idea that a pattern should represent 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 and related design forms rather than algorithms, and typically based on harder-to-measure forces and 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 concern stylistic issues -- whether a pattern is written in an understandable way. Try analyzing some real patterns so we can develop better evaluation guidelines.

  7. What's the difference between a pattern and a framework?

    A framework is not a pattern, but may have been built using patterns. Also, the use of the framework may be described via patterns.

  8. What's the difference between a set of patterns and a style guide?

    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.

  9. What's the difference between a pattern and a programming idiom?

    A pattern can characterize an idiom, along with descriptions of how, when, and why to use it.

  10. Can patterns describe standard OOP concepts like inheritance?

    Sure; similar answer.

  11. Are patterns programming-language-independent?

    Some (even most) are.

  12. What's the difference between a pattern and a data structure?

    The designs described in (only) some patterns consist of specialized data structures and related techniques.

  13. Why bother writing patterns that just boil down to advice my grandmother would give me?

    Because some patterns are so good and useful that even your grandmother knows them. Writing them down makes the context, value and implications of the advice clearer than your grandmother probably did.

  14. Must all patterns be so [low-level / high-level / general / specific / abstract / concrete] as [SOME PATTERN]?

    Of course not.

  15. What is the theoretical basis of Patterns?

    No formal basis in the usual sense. Patterns can express design notions stemming from all sorts of theoretical and empirical bases. On the other hand, many of the notions of pattern-directed design stem from classic and not-so-classic works on ``design theory'' across diverse fields of engineering. (See the bibliographies of papers listed in the Patterns Home Page.)

  16. Can patterns be expressed in [SOME PARTICULAR FORMALISM OR NOTATION]?

    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.

  17. Wouldn't it be nice to have some patterns-based CASE tools?

    Maybe, but patterns are about communicating from one person to another. If the medium enhances communication with other people it is good. If it merely makes the machinations of the patterns executable by a computer it isn't.

  18. What's the difference between a pattern language and a set of patterns?

    Arbitrarily little. Alexander's use of the term ``language'' is unconventional but not wrong. If you squint at and overformalize them, pattern entries are ``production rules''. If you remember your automata theory, you'll recall that sets of production rules are one way to characterize recursively enumerable langauges.

  19. Why aren't there more patterns about [WHATEVER]?

    Because you haven't written them. If you're interested, you more than likely know something, and if you know something you can write patterns.

  20. How many patterns are there?

    Some people think there are relatively few undiscovered patterns that nearly everyone ought to know about. Some people think that there are a great many more domain-specific patterns that need to be written. Both may be right. Try writing some more patterns so we can find out.

  21. Won't the existence of lots of patterns lead to problems in finding, indexing, using, and maintaining them?

    Maybe, but it doesn't seem very useful to worry about this until more patterns come into existence.


    Probably so. Although if you do, you might no longer be following much of the method beyond its notation.

  23. Are `requirements' patterns different than `analysis' patterns different than `design' patterns different than `programming' patterns?

    This might be fun to discuss, but is too murky to answer definitively since, among other reasons, each individual pattern ties together problem-space, design, and construction matters within some context and level of concern.

  24. Is the use of patterns necessarily iterative?

    In principle, you could be very lucky and have a problem for which there is already a complete set of patterns, and in which each application of a pattern flows into the next, leading to a final product without ever backtracking. But people are never this lucky.

  25. Is there a recommended development process associated with the use of patterns?

    Probably so, but even though we discuss it a lot, we don't know what it is. Use patterns so we can find out.

  26. Does the use of patterns have any effect on business practices and software economics?

    Same answer.

  27. Can software development process and organization be described using patterns?

    Sure, there are several examples. They tend to generate controversy.

  28. Can patterns serve as the basis of software design handbooks?

    Yes, in fact, most interest and work in software patterns arose among people trying to figure out what should go in such handbooks.

  29. How would a patterns-based software design handbook differ from handbooks used in other kinds of engineering?

    Among other differences, fewer tables of values of physical constants.

  30. Wouldn't it be more useful to teach people to write patterns rather than teaching them to use a bunch of existing patterns?

    Both are needed. Neither is more needed.

  31. Why aren't Alexander's patterns universally used by architects?

    There seems to be no single reason. 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.

  32. Can you use patterns in very large development efforts?

    People have reported that they do so.

  33. Are patterns over-hyped?

    Of course. It is impossible to avoid.

  34. Do patterns really work?

    Please ask a more specific question.