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.
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''.
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.
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.
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.
You can call them anything you like, but its too late to change what most other people call them.
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.
A framework is not a pattern, but may have been built using patterns. Also, the use of the framework may be described via patterns.
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.
A pattern can characterize an idiom, along with descriptions of how, when, and why to use it.
Sure; similar answer.
Some (even most) are.
The designs described in (only) some patterns consist of specialized data structures and related techniques.
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.
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.
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.
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.
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, 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.
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.
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.
Sure, there are several examples. They tend to generate controversy.
Yes, in fact, most interest and work in software patterns arose among people trying to figure out what should go in such handbooks.
Among other differences, fewer tables of values of physical constants.
Both are needed. Neither is more needed.
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.