Pattern Language Taxonomy

I believe that Wolfgang Press' basic concept of determining what elements change and which remain concept provide us with the most likely basis for a taxonomy. What needs to undergird this whole effort is a drive to define the principles that make these patterns work in which situations. We have a number of these principles, now we just need to see how they apply and determine causal factors. [trivial detail left as an exercise for the reader. :-) ] -- ARickAnderson

I'm not sure what you're referring to, but Pree's distinction always left me with an empty feeling. I've just shepherded a paper about classifying design patterns using Pree's distinction, but I think it only met with very limited success.

I think that there are many, many more issues involved in a Taxonomy of Patterns and Pattern Languages than Pree's work. The issues involved are usually completely orthogonal to "fixed" vs "changing".

For instance, some of the axes are:

Are the patterns in this language Architectural, Design or Coding Patterns (Idioms)? Are the patterns general purpose, or do they apply only to a specific domain? Are they patterns about people (Organizational patterns), software, or something else?

If you want a really tough problem, try to come up with a good taxonomy that can handle all of the patterns in the first two PLoP books. The editors made a Herculean effort to shoehorn them into topics in each volume, but it's much more interesting to try and figure out how they fit together across volumes.

I think what we'll end up with is a multi-dimensional net. Sort of like the WikiWikiWeb!

-- KyleBrown

First, I believe that WolfgangPree's work establishes a PatternTaxonomy, not a PatternLanguageTaxonomy. It tells how to categorize patterns in something like a PatternSystem, but not how to weave them in a language. There are lots of these things around, and I don't like them because they totally miss the QWAN: see http://sys3.cs.usu.edu/students/RaghuKrishnaswamy/OSMTemplates.html or http://csg.uwaterloo.ca/patterns.html; there are lots more).

Second, I believe that we can capture the essence only of non-generative patterns using commonality analysis. If it can be regularized in terms of what is stable and what changes, then the design principle is subject to a more general paradigm, and more general principles of formulating abstractions. I rail a bit about this in "A Professional Dilemma" (the dilemma between patterns and paradigms) in the CppReport 8(3), March 1996, 80-89.

Alexander makes clear the major principles of a PatternLanguageTaxonomy, which he calls "large patterns include smaller patterns." It is a refinement hierarchy (well, a DAG actually, which is why the WikiWikiWeb is such a cool way to capture it). Note that it is not a containment hierarchy: the smaller patterns don't necessarily work on the same artifacts scoped by the larger patterns they elaborate. Nor is "refinement" the same as "specialization" in the subtyping sense: you can't substitute a small pattern to do the job of a larger one. While it's hard for me to describe here, the concept is intuitive from the PatternLanguage book.

In practice, I find that the following rules guide a PatternLanguageTaxonomy:

Patterns should encapsulate forces so they can be individually applied
The ContextSection? of a pattern should plug into the ResultingContextSection? of a larger pattern
The ResultingContextSection? should suggest the patterns that ensue

I'm currently exploring whether PatternLanguage are closely related to ArchitecturalStyle; I have a hunch that we should be thinking of them that way, instead of thinking of them as frameworks. If that's true, it will be difficult to fit pattern languages into any taxonomy - at least as difficult as making a taxonomy of English.

-- JimCoplien

When we suppress differences for the purpose of abstraction, we can determine commonality even if the associations are initially arbitrary. We learn abstractions before we learn exceptions. Listen to a young child in any language. They initially over-generalize and people call it baby-talk because they haven't learned the exceptions.

By selecting non-subjective factors in analysing design patterns, we can better see how and WHY certain design patterns are related. Then we examine these patterns and see how they work in different contexts [an oxymoron, under current definition of DP].

From this analysis, we can empirically determine causal factors just like any of the physical sciences. Why certain patterns work in some contexts and not in other contexts, leads us to the basic principles. Once we know these principles, we can predict new patterns. Robert Martin's recent list in CppReport lists several of these principles, some of which have roots that go back to Constantine and DeMarco.

-- ARickAnderson

I agree that pattern languages are more closely related to architectural style than to frameworks. I think that is one of the reasons I have not been happy with patterns for architectural styles like PipesAndFilters. I think it takes a PatternLanguage to describe those things, not a single pattern. -- RalphJohnson

I think that ARick missed the point on generalization here. I don't think that suppressing differences for the sake of finding commonality is necessarily the right approach. I've never seen things work from "grand principles" down. Instead, I've found that when looking for ways to group patterns (e.g. writing a language, which I think is more helpful in every way than a dry taxonomy) you look for "clusters" first. Clusters are small groups that work together based on composition (these fit together in this way) rather than inheritance (these are alike because they all do X).

Contrary to ARick's contention, people do NOT learn to talk by working from general to specific. My two-year old is constantly confusing specifics for generals. It's not "drink", it's "Juice" or "Milk", regardless of what is actually on the table. Generalization is something that is learned much later.

To see a better illustration of the dangers of generalizing and looking for false analogies, look at GeologicTaxonomy.

-- KyleBrown

I (more or less) agree with Kyle's take on this, and when organizing patterns into languages I've looked for clusters of related patterns, and then organized the clusters into some sort of superstructure - I call these clusters PatternLanguageFragments, because they should eventually come together to form a pattern language.

To build clusters, I think about three RelationshipsBetweenPatterns: PatternUses, what Cope calls refinement, where one pattern "plugs in to" another pattern; PatternSpecializes, which is like inheritance (which I originally called refinement, but that's confusing), and PatternConflicts, where two patterns present different solutions to similar problems.

Trying to manage any more than about twenty patterns is *hard*. More on my attempts is at http://www.project-download.com/php-projects/ l#classify.

-- JamesNoble