Maintained by Doug Lea . Mail comments to dl@cs.oswego.edu.
Hiroshi Yuki and friends have provided a Japanese translation.
Last updated NOvember 2000.
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 information about patterns, including links to online patterns, papers on patterns, descriptions of books dealing with patterns, listings of conferences, and patterns-related mailing lists, see The Patterns Home Page.
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''. However, the shortness of this slogan can cause confusion. Expanding each of these terms out just a little helps:
Discussions of more extensive definitions can be found at the Patterns Home Page and at WikiWikiWeb.
You can call them anything you like, but its too late to change what most other people call them.
The notion of a pattern is very broad, and can be applied in all sorts of contexts.
The ``Gang of Four'' (GoF -- Gamma, Helm, Johnson, and Vlissides) Design Patterns book is almost entirely devoted to patterns dealing with micro-architectures (also known as object structures) -- static and dynamic relations among objects (and/or their classes) encountered in object-oriented development. The term design pattern has come to refer to these kinds of patterns. These have become most common kinds of patterns described in the literature.
Some people incorrectly use the term design pattern to refer to any object structure, even if it is not in any sense a pattern. Please don't do this.
Existing software-related examples include:
while(*dest++ = *src++);
Additionally, patterns have been applied in several fields outside of software development.
A pattern may be mainly about one of these things, but the thing alone does not comprise a pattern. A pattern describes how and why any of these may apply in a given development context, along with guidance for applying them.
A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product.
Some (not many) solutions are amenable for description via implementations (as classes, frameworks, tools, or whatever) that provide developers with just about everything they would need to know or do. Even so, the code itself is not the pattern.
The solution described in a pattern may be phrased as a series of steps similar to those seen in How-To guides and cooking recipes. But again these steps form only one aspect of a pattern. Also, patterns aspire to greater scope and generality of context, and greater authoritativeness in identifying and resolving forces than seen in typical How-To guides.
There appears to be some overlap.
There is not a central clearing house for patterns, but it is not too hard to find them. Here are some starting points:
Alexander is an architect (in the sense of buildings, not software) who invented patterns. A brief biography and links to related readings and web pages can be found in Nikos Salingaros's Notes on Christopher Alexander.
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. No two of the existing books containing patterns use exactly the same format. Alternatives include the purely narrative Portland Form. Probably 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.
Across different forms, common requirements for the structure and content of patterns include:
The notion of force generalizes the kinds of criteria that software engineers use to justify designs and implementations. For example, in the classic study of algorithms in computer science, the main force to be resolved is efficiency (time complexity). However, patterns deal with the larger, harder-to-measure, and conflicting sets of goals and constraints encountered in the development of every artifact you ever create. For example:
Tres Seaver adds: The usage is far more ancient than software: in architecture, or in mechanical / civil engineering, a designed entity exists in relationship to a system of interacting physical forces. Designs which do not resolve each force, and the system as a whole, fail (e.g., the Tacoma Narrows bridge failed to resolve dynamic loading due to winds; the bonfire at Texas A&M failed to allow for the loads induced by moving workers). By extension, designs must satisfy other demands which interact in complex, and sometimes unforeseen ways; the term "force" was extended to cover these cases.
Alexander's descriptions of patterns 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 the kinds of harder-to-measure forces described in the previous question.
It is usually impossible to analytically ``prove'' that a solution optimally resolves forces. (In fact, it is hard to define the notion of ``proof'' here, or even to see what use such a proof would have.) On the other hand, it is all too easy to come up with ``just-so'' stories that provide wrong or deceptive rationales for solutions. Even the most concientious pattern authors sometimes don't fully understand why a solution works as well as it does, or appreciate its full range of applicability. As Ralph Johnson once posted:
It is often hard to figure out the problem that a pattern solves. You can tell it is a pattern because you see it so often, and you know it is a good pattern because introducing it makes the world a better place. But when you look at the world, it is hard to tell why things are the way they are. I think the way we figure out the problem that a pattern solves is by watching ourselves as we design things. What are the conditions that trigger our use of a pattern?I think the main reason that Alexander didn't always describe the problem of a pattern is because he didn't always know. That is certainly why the GOF book doesn't describe the problem well. It is not that the format led the authors to ignore the problems, it is that their understanding of the problems led them to their format.
For these reasons, the patterns community expects that arguments be backed up with:
Until such evidence is provided, a pattern is sometimes called a proto-pattern -- a candidate for being a pattern.
There's no good short answer. You'll have to read The Timeless way of building.
Overly-geeky patterns-enthusiasts like to pretend that Alexander never wrote about QWAN. Overly-flakey ones like to pretend that QWAN ties patterns to just about any mystical, weird-sounding metaphysical rantings you'd care to name.
Perhaps ideally not -- sets of good patterns would steer you clear of the infinitely many bad designs (sometimes called antipatterns) you could come up with, as well as all of the contexts in which it is not appropriate to apply a given pattern. But some ideas are so bad yet so prevalent that they deserve explicit mention. One way to do so is to include a ``Common traps and pitfalls'' section in a pattern description. Descriptions of bad solutions (misfits) can form part of the motivation, rationale or forces for a good solution. Patterns may also describe ways of transforming bad solutions into good ones (sometimes in ``Before/After'' or ``Repair'' sections).
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 by discovering those forces that differentiate alternative solutions. Even when they are differentiated, there's also the stylistic issue about whether to group a set of patterns sharing most context and forces in the same presentation.
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.
Of course not.
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.)
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.
For the same kinds of reasons that you should reuse good code: Benefitting from the knowledge and experience of other people who have put more effort into understanding contexts, forces, and solutions than you have done or want to do. Further, patterns can be more reusable than code, since they can be adapted so that you can build software to address particular special circumstances that cause you to be unable to reuse an existing component.
Patterns also give developers common sets of names and concepts for dealing with common development problems, thus enhancing communication.
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.
A pattern language is a set of interrelated patterns, all sharing some of the same context, and perhaps classified into categories.
This term is due to Alexander. 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.
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.
Here are some common recommendations:
See also Ward Cunningham's Tips for Writing Pattern Languages.
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.
Maybe.
Probably so. Although if you do, you might no longer be following much of the method beyond its notation.
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.
Probably so, but even though we discuss it a lot, we don't know what it is. Use patterns so we can find out.
Same answer.
Both are needed. Neither is more needed.
Common recommendations include:
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.
People have reported that they do so.
Of course. It is impossible to avoid.
Please ask a more specific question.
Written by Doug Lea, and released into the public domain.