Patterns

From Patterns

The concept of patterns and Pattern Language are tightly coupled. Standalone patterns are 'orphans' that may express a useful idea, but are limited and 'single purpose'. Taken in isolation, an individual pattern runs the risk of being used out of context, similar to the expression "to a hammer, everything is a nail". Interesting problems rarely are solved through 'silver bullet' solutions. It is the relationship between patterns that creates a rich palette that can be customized to a specific context and from which effective solutions can be created.

Note: I will capture questions and answers about patterns in the Discussion tab, eventually integrating material into this page.

Contents 1 Definitions of a 'Pattern' 2 Principles vs. Patterns 3 Structure of a Pattern 3.1 Pattern Template 3.2 Examples of Patterns 4 Characteristics of Good Patterns 5 Pattern Language

Definitions of a 'Pattern'

What Are Patterns emphasizes the structural and systems aspects of working with patterns through defining patterns as "A recurring structural configuration that solves a problem in a context, contributing to the wholeness of some whole, or system, that reflects some aesthetic or cultural value." The term configuration refers to a "special kind of rule that contributes to the overall structure of a system, that works together with other patterns to create emergent structure and behaviour."

Fil Salustri's Using Pattern Languages in Design Engineering states: "A pattern is a natural-language, context-dependent description of a solution to a class of problems, that is both generative and descriptive." Whereas knowledge and method are usually communicated separately, the concept of patterns combines content and methodology. The patterns and relationship between patterns captures knowledge about a domain in a rich and accessible fashion, describing both the 'what' and the 'why'. The construct of the pattern and the Pattern Language methodology provides the 'how' - instructions for generating solutions specific to a problem and a context.

Principles vs. Patterns

Selected definitions of principle:

• "Principles are overwhelming obvious ideas that are often accepted as a matter of faith" (Jón Erlendsson, University of Iceland)
• "A basic or essential quality or element determining intrinsic nature or characteristic behavior" (The Free Dictionary)
• "A rule used to chose among solutions to a problem" (Wiktionary)
• "A basic generalization that is accepted as true and that can be used as a basis for reasoning or conduct" (WordNet)

Patterns share many of the characteristics of principles, in that they:

• describe how 'things' work
• provide guidance on developing specific solutions

Different from principles, patterns explicitly describe:

• the context in which the pattern is useful
• the underlying problem, including the drivers or forces that cause it to occur
• the specific steps required to apply the pattern in generating solutions
• a range of sample implementations of the pattern
• any caveats, restrictions or 'gotchas' that limit the applicability of the pattern
• how the patterns relate to each other in a hierarchy or network, ideally mapping the full breadth of a domain of knowledge

Maibritt touched on many of these aspects in Background to Draft Principles of Ecosystems, such as:

• "... it is not always easy to make distinct principles as often they are linked."
• "... it is not clear if some of the principles in the draft list are not in fact subsets of others, or that some important principles are not there yet."
• "... such lists, particularly the simplified ones really need some kind of explanation for each principle so some of the more subtle or complex aspects of each one are not overlooked or missed out ..."
• "Each principle represents a lot of information that might not be immediately apparent."

None of the ecosystem principles are patterns - at best, they may suggest the pattern name. Principles normally do not explicitly state the problem that they are solving, nor do they define the context or the consequences.

Structure of a Pattern

According to Christopher Alexander's A Pattern Language: Towns, Buildings, Construction,

“Each pattern is a threepart rule, which expresses a relation between a certain context, a problem, and a solution. As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves. As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.”

Fil Salustri in Using Pattern Languages in Design Engineering uses a more design-oriented definition: "a pattern models the relationship between a context, a system of drivers that occurs repeatedly in the context and that is in an undesirable state, and an entity that allows these drivers to be resolved, bringing about a more preferred state."

Pattern Template

Fil has proposed a form for documenting patterns that incorporates the descriptive and generative aspects of patterns. In addition, it makes clear the limitations of the pattern

1. Descriptive Pattern Name: An evocative 'shorthand' for the pattern that helps communicate the intent to others. In some implementations, the confidence in the specific pattern is indicated by zero, one or two stars.
2. Problem: Starts with a concise statement of the problem or need that must be addressed. This is followed by paragraphs describing the context where this particular pattern can appropriately be applied in neither an excessively narrow nor overall broad fashion. Specific contraindications may be listed. Lastly, the forces or drivers that need to be resolved or balanced are listed in point form. It is the combination of these drivers that create the problem, often through tradeoffs or contradictions that make the problem difficult to solve.
3. Therefore: Starts with a short description of the solution, in the form of a 'directive' to the user. Additional paragraphs describe the specific tasks involved, how the result of the solution is used, why the solution works, and the relationship of the solution to other patterns. Using the pattern, the user should be able to create a specific solution that will balance the drivers underlying the problem. The user should also gain insights as to why the pattern works.
4. But: Solutions have consequences, hopefully positive, sometimes negative. Good patterns describe all the consequences, to avoid implementation surprises. Solutions can also affect the context of the problem. For example, a solution may eliminate a contradiction between forces or drivers by interpreting the forces/drivers in a novel way. A solution may also act at a different level within the system from that of the original context, solving the problem at the super-system or sub-system. Diverse examples of successful (and possibly unsuccessful) implementations are useful to make the pattern 'real'. <See Discussion on 'But' Section of Pattern Template>
5. See Also: (optional) This section can point to other patterns not explicitly mentioned elsewhere

See Discussion with Tom McKeag on Pattern Structure for two ideas on how to categorize patterns.

Examples of Patterns

• Using Pattern Languages in Design Engineering includes three sample patterns
• What Are Patterns walks through a sample pattern to explain their version of the template

Characteristics of Good Patterns

Using Pattern Languages in Design Engineering lists characteristics associated with patterns that have become widely adopted:

• Generative: Guides us in creating implementations of the pattern how patterns in a flexible, dynamic and robust fashion.
• Descriptive: Describes what the implementation might look like in a structural sense.
• Explicative: Explains why solution is appropriate in relationship to alternative solutions.
• Recurrent: Pattern should be successfully applied in at least three different instances.
• Non-definitive: Suggests alternative ways of solving the problem (see Pattern Language for a way of finding 'nearby' patterns).
• Context sensitive: Applicability of pattern must be well defined, neither too broad nor too narrow.
• Relational: Between context, problem and solution as well as with other patterns (see Pattern Language)
• Assistive: Useful and relevant.
• Evolving: Represents a living document that is open to revision.

On the Feb. 6th call, Fil mentioned Brad Appleton's Patterns and Software: Essential Concepts and Terminology. Some highlights:

• "If ... a pattern must be both a process and a thing, then a pattern must describe not only the process that creates that thing, but also the thing created by that process."
• "A pattern is where theory and practice meet to reinforce and complement on another, by showing that the structure is describes is useful, usable, and used!" (my emphasis)
• "It solves a problem: Patterns capture solutions, not just abstract principles or strategies."
• "It is a proven concept: Patterns capture solutions with a track record, not theories or speculation."
• "The solution is not obvious: .... The best patterns generate a solution to a problem indirectly .."
• "It describes a relationship: Patterns don't just describe modules, but describe deeper system structures and mechanism."

Pattern Language

As mentioned throughout this page, patterns gain value when they are arranged in a network or hierarchy, based on a "grammar" that defines a Pattern Language.