Pattern Languages Are Patterns Too

The way that I believe the "pattern form" fits for describing pattern languages is as follows (using CanonicalForm or CoplienForm - the section names of course wouldn't need to be exactly the same, but I think you get the general idea):

NAME -- A pattern language should have a name, to make it easier to think of and refer to as single unit (just like patterns).

PROBLEM -- A pattern language presents patterns which interact to address a shared fundamental problem. Making specific mention of what the overarching problem is that the resulting "architectures" will address is extremely insightful IMHO. You can think of this as the INTENT if you prefer GoFform.

CONTEXT -- There are also some shared contextual elements regarding the applicability of all the patterns in a pattern language. These are useful to state up front to set the global, common context and to avoid having to redundantly repeat throughout the language. It would also be useful for identifying the common cultural context within the particular field or domain. This would be similar to the APPLICABILITY section using GoFform.

FORCES -- Just as there are shared contextual elements, there are also shared forces. Some of these might be common principles or leitmotifs for the overall problem domain. This would correspond roughly to the MOTIVATION section using GoFform.

SOLUTION -- the "architectural solution" provided by a pattern language is the sequences of patterns to apply and their rich interactions. One can break the solution section down into GoFform for more detail:

STRUCTURE -- it helps to have a kind of birds-eye view of the structure of the patterns into related groups and subgroups and to see some of the relationships between them (like in the inside back cover of the GoF book).

PARTICIPANTS -- the participants are the individual patterns themselves. In this case one can give thumbnails for all the patterns (like the inside front cover of the GangOfFour book) and then include (either immediately, or a bit later on) each of the individual patterns in appropriate hierarchical order according to the grouping criteria used for the patterns.

COLLABORATIONS -- the collaborations are the dynamic interactions between the patterns. In addition to showing static structure, dynamic and temporal pattern relationships are useful to provide pictures of how to weave patterns together (not to mention some general comments about the overall inter-workings among the patterns).

CONSEQUENCES -- shows the trade-off preferences and predilections of the particular architectural style. This would give some insight as to some of the underlying "value system" the the language emphasizes as part of its overall problem solving approach.

IMPLEMENTATION -- this section can more clearly discuss some of the different sets of possible paths for applying the patterns in the language ("scripts" of pattern application sequences if you will). This is especially useful for showing how the language can be used to provide overall "architectural" solutions for different environment.

RELATED PATTERN LANGUAGES -- Just as no pattern is an island, neither is a pattern language. Pattern languages can also work together to address larger issues. A set of coding patterns might work together with a set of testing patterns, and a set of process patterns, etc., and these larger connections between languages are crucial for gaining a deep "systems thinking" perspective.

KNOWN USES -- This one is the toughest and might not be as applicable for patterns languages as for patterns (at least not yet). In theory, this would have to describe other uses of the entire language (or something very similar). These would be extremely hard to find IMHO and while it would be useful, Im not sure if its feasible to have a kind of "rule of three" requirement for pattern languages before proclaiming them as such.

A Pattern Language is both an Architecture and a Style

So if a "pattern" is supposed describe a thing, and also be the thing itself ("both a thing, and a process to create a thing"), then how does this relate to a pattern language? Pattern languages supposedly describe architectures or architectural styles. Yet a skillfully crafted a pattern language is itself a work of architecture IMHO (see NikosSalingaros' paper on The Structure of Pattern Languages[1])

Finding the most effective way to decompose the language into sections, subsections, subsubsections, ... is a kind of architectural structure. Coming up with appropriate grouping of the patterns into categories and subcategories and then exposing the relationships between them so as to minimize the number of references to concepts that have not yet been explained is no mean feat (as Im sure anyone who has written a textbook can tell you). In a very real sense, the pattern language is the architecture (similar in many ways to how TheSourceCodeIsTheDesign).

A PatternLanguage really is a kind of "collective" of patterns which, from a whole systems perspective, exhibits the attributes and properties of individual patterns.

-- BradAppleton

See also A Pattern Language for Writing Patterns by GerardMeszaros and Jim Doble in the last chapter of the PatternLanguagesOfProgramDesign-3 book (originally presented at EuroPLOP'98). It is highly recommended reading for those with a penchant for pattern writing. -- AlistairCockburn and BradAppleton

This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006