Pattern Definition Thread

The following is a thread of discussion on the definition of the term "Pattern".

See http://hillside.net/patterns/definition.html

Various people write things like this:

: "A pattern is a proven solution to a problem in a context."

I suppose I cannot argue with the actual words, because they are not obviously false, but I fear that among the software crowd, especially the CS-oriented ones, this represents a misconception.

Alexander writes:

: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

I'm sure that because he wrote this many feel that the rewording above is a fair copy. I don't think it is. Alexander is capable of writing simple sentences when the thought he wishes to express is simple. He could easily have said "a pattern is solution to a problem in a context" - he uses most of these words already.

But, instead he wrote the paragraph above and he went on to explain:

: 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 is relevant.

If you walk into a room and you ask Alexander to list all the patterns he sees, he will not look for sheets of paper with patterns written on them, he will look at the room and tell you the ones he sees in the spatial configuration. Similarly, if asked what patterns there are in a software system, an astute patterns person will look at the code and try to list them off.

Each pattern is both a statement in a pattern language and a configuration in a program. I don't think the words in the first quote above capture that. For example, according to it a pattern might be:

: Problem: How do you allocate objects in memory?
: Context: A large OO system in a virtual memory computer.
: Solution: Run some typical problems and figure out which objects communicate frequently in a time locale and put them on the same page.

This is not a pattern. It is merely a solution to a problem in a context. It can be made into a pattern by talking about configurations of objects that communicate according to a particular definition of efficiency in a virtual memory system. One can imagine other things that might be a pattern according to the over-simple definition, such as the way to figure out the number of things in a "this many sets of this size" problem is to use multiplication.

Alexander could have written a 1-sentence definition of what a pattern is, or an essay, but instead he wrote a 550-page book to do it. Because the concept is hard.

I would prefer to see a definition that was more mysteriously worded with a reference to a longer piece, such as

: Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves. [See "A Timeless Way of Hacking."]

-- RichardGabriel

A definition is a tool, and we use tools as they work. Definitions may be O.K. for someone who wants cocktail party familiarity with patterns (or who wants to sprinkle the word in a methodology book) but I don't think you can appreciate patterns from a definition, any more than you can appreciate a good painting or a good book from the Webster definition of "art."

When people come to me, and they want to understand patterns, I often give them advice that Kent taught me to give them: go and write some patterns. Struggle with the forces. Struggle with what you really know that is really valuable. Assemble some patterns into a pattern language. Talk to some patterns folks and other designers about what you're doing along the way.

I like Dick's "definition" but his mail has to be taken as a whole. If you want the textbook definition, you'll probably have to read the whole 550-page book. Will understanding the definition help make you a great pattern writer, or apologist, or user? Maybe - but you'd be further ahead to write some patterns.

We started publishing the results of the PLoP conferences as examples worthy of emulation. We've learned a lot since the first PLoP, so some of the examples aren't as great in retrospect now as we thought they were at the time. But they're still pretty good. Reading patterns is a good way to get a feel for the pragmatics of style and presentation.

Beats a definition any day. Start with any of the definitions that Dick or Rajendren presented, and try writing one. Write a few. I don't think you can understand the definition without doing so.

-- JimCoplien

Alexander writes and teaches through piece-meal growth, in a way that is compatible with his paradigm of using pattern languages. My view is that embedded in TTWOB there is a pattern language for "education" through piece-meal growth.

Why do I say that? Alexander directs us to read first the "Detailed table of Contents" at the beginning of TTWOB. Once we do that, we have a clear picture of the TTWOB as a whole. Then he guides us to read just the italicized text and to look at the pictures. Then he guides us to read every word, paragraph and page of the book ever expanding our understanding. In every iteration, we increase our understanding of the previous concepts and we incrementally add new ones that fit in harmony with the ones previously learned. At every step we experiment, writing patterns, creating models and painting pictures.

This process is remarkably similar to "unfolding" a whole through a pattern language. It is as if a pattern language for "teaching" was being applied to our minds to make us learn through an iterative and incremental method (Gest-Alt). We also have to remember "he DID this on purpose", even though he may have not written the pattern language for "educating with an iterative approach". Maybe after thinking about patterns for so long, you start doing things like that - using the "patterns paradigm" for just about everything you do, maybe even effortlessly and unconsciously.

IN a sense TTWOB is a system. He architected this system (Architect Controls Product), and by following his proposed iterative cycle we develop (Developer Controls Process) mental models and scenarios (Scenarios Define Problem) of this system in our minds iteratively and incrementally (Named Stable Bases).

What does this have to do with the definition of patterns. Well, we could try the same for defining patterns. First we can use a sentence that conveys the overall meaning, then a paragraph, then a page, then a chapter, then a book, then experience, constantly iterating and expanding our understanding and eventually "unfolding" the whole meaning.

I found this 'poem' fragment that conveys some of the Alexandrian views:

We are blind until we see That in the human plan Nothing is worth the making If it does not make the man.

Why build these cities glorious If man unbuilded goes? In vain we build the world Unless the builder also grows.

- EdwinMarkham?

-- MichaelBeedle

Both definition by A.Rick Anderson and Dick Gabriel means the same, but I feel a definition should be simple and short. Simple here means 'simple English' and short means shorter sentences. The definition is mainly forwarded to a new member(student). Therefore a simple and short definition will be better -

"A PATTERN IS A PROVEN SOLUTION TO A PROBLEM IN A CONTEXT."

: - by RickAnderson?

A longer definition may confuse a new learner. But a longer definition is necessary to be a follow up.

"Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves. [See "A Timeless Way of Hacking."]"

: - by RichardGabriel

-- RajendrenSubramaniam

(here Dick gives his lecture on WhereDoPatternsComeFrom, and a PatternMiningThread breaks off.)

Why do we need a definition?

Like Jim was saying earlier, and Kent advises, we the "patterns practitioners and writers" won't know what patterns REALLY ARE until we read, write, discuss and apply many of them. For example to learn the GOF patterns, I wrote a sample program for each one, I read every line in the book, I talk to people at work every day in these terms and STILL I have many variations and subtle points to learn for each one of them. However, it is impractical to expect that everyone should read, write, discuss and apply patterns to that extend to understand what they are.

Tell that to a CIO to whom you are proposing a multi-million dollar enterprise architecture: "Look I need 8 million dollars to re-architect your system architecture using patterns. I can't tell you what they are, but if you want to know what they are, write some. Here is a book by Alexander you can read to get started. BTW, here are my rates as a consultant." He will think of you as an "insultant" and you will be out the door so fast you won't have to time to blink.

The typical 'patternite' will go through TTWOB and "A Pattern Language", will read GOF, POSA, Pree's "Design Pattern for OO Software Development", Coad's "Object Models, Strategies, Patterns, & Applications", Gabriel's "Patterns of Software", Coplien's "Software Patterns", Fowler's "Analysis Patterns", PLOP 1,2,3, ...N, the OOPSLA paper, and all other relevant articles and related web pages, AND more importantly he will read, write, discuss and apply patterns EVERY DAY. He is not the one I am concerned about. He will live and breathe patterns. My concern is for all the "others" that need to know about patterns but will not go beyond a 'self-contained one liner' definition.

Who are these others? The object newcomers, the new 'patternite' generation, the venture capital firms, the executives (CEOs, CIOs, VPs, Directors, etc.), the project managers, the buyers of new products, the marketing team, the testers, and all the people that WILL not have direct exposure to patterns, will never write a pattern in their lifetime BUT need to have that 'short eloquent one liner' of well structured English to know what the hell we are talking about.

Just as a short summary, here are the 'grapevine' definitions and statistics. Sorry if I missed 'your' favorite definition. You also know what they say about statistics, so you have been warned!

Definition 1. The one everyone knows. Going from (my) statistics, the most accepted definition - the one you hear quoted from most everyone, is:

: "A pattern is a solution to a problem in a context."

This is the definition that 'I use the most' and almost everyone that I know uses. Sometimes I go for 2,3,4, 7 though currently I am leaning for 9.

Definition 2. Alexander's (TTWOB pg. 355)

: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

This works for the purist but people don't grab its meaning very well, at least in (my) experience and (my) statistics.

Definition 3. The 'recurring' one

For example Jim Coplien wrote: "It is the nature of patterns to recur."

So we could easily write:

: "A pattern is a 'recurring' solution to a problem in a context."

This certainly takes care of the "Known Uses" section. Writing the few patterns that I have written this has always been my main concern (read FEAR): Is this something that people REALLY do? How many of them?

Definition 4. The proven one

"A PATTERN IS A PROVEN SOLUTION TO A PROBLEM IN A CONTEXT."

: - by RickAnderson?

Unfortunately "PROVEN" is not provable until we have recurring. And that is only proven by statistics. And statistics are not necessarily proof. So what does it mean to that a solution is "PROVEN"? How do we certify that a solution is "PROVEN"? I don't know.

Definition 5. The long one

RajendrenSubramaniam wrote:

the longer definition may confuse a new learner. But a longer definition is necessary to be a follow up.

: - by RichardGabriel
: - from A Timeless Way of Hacking.

Your CIO is lost, He thinks you are "strange". Shortly after you started the presentation he started looking out the window probably thinking: "When are these 'techies' going to learn how to sell and speak in business terms?". You lost the contract and on your way back from the multi-million dollar presentation, you keep asking yourself: "What happened? I was just getting started and suddenly he ended the meeting... He must be really busy." Then again he may not, he may be just as well read, and as "strange" as you are, if not more so than you, so this may work in some "contexts".

Definition 6. Goedel's definition

Sometimes you have to think out of the box. If our definitions rely on self-referencing, are not self-contained, or lack semantic information, we may have to define patterns in a "larger" context.

Definition 7. The Tao definition of patterns

: - Tao definition

(Read in between the lines. That right, I didn't forget the definition. It is meant to be empty text. This also works for me ('just do it!'), but it won't work for the CIO, he needs the 'self contained one liner'!)

Definition 8. The egoistic definition

Please write YOUR definition here. Really, it is OK to use it - as long as you don't tell anyone. That's what I do with Definition 9.

Definition 9. The one using Complexity

"A pattern acts as a 'strange attractor' that provides a solution to a problem in a context, with stable equilibrium points 'at the edge of chaos' bringing out the QWAN."

: - MichaelBeedle

My concern with the other definitions is that QWAN or references to Complexity are not mentioned. I am interested in a set of compatible solutions, a "pattern language", that brings that magical QWAN that not even a 'recurring solution' may guarantee.

It is something that I think is related to Complexity, the fact that they sit at "the edge of chaos", which gives patterns the QWAN. You can certainly see that with GOF. For example in applying, a "Factory Method" a "Template Method" or a "Strategy", my position as a designer is: "I don't know exactly what I want to create, or how to process it. I have to allow the design to be flexible, extensible, adaptable, etc.". An observer from the outside looking in may think of my design: "But, you are allowing chaos! Don't you know EXACTLY what you want to do?", and I would answer: "No. I want to have options, but just for these well chosen behaviors."

Surely this last definition will be appealing to the CIO!

Regards,

-- MichaelBeedle

What struck me about Alexander's writing:

The builders had been the indigenous (though not by definition "primitive"!) people who knew the "timeless way" (so to speak) by building to meet their needs (facility and affordance) and evolving their experience over hundreds and thousands of years.
The recoverers are the architects who are otherwise out of touch with the indigenous, timeless, way(s).

Comparing this to our current software culture(s):

We have an extremely brief history.
We have greater communication and a greater documentation of our history.
The sets of best builders and best recoverers have a large intersection.

The best I am hoping for out of the software patterns effort is for the best builder/recoverers to share their knowledge with the rest of us. The "timeless way" will have to come with, well, time.

Still, I am glad there are people like rpg aiming at a higher mark than mine. I need to remember that when I hear references to "the timeless way" and "QWAN" and my initial reaction is "phhhhhhhbt!"

-- PatrickLogan

I'm simple-minded. Let me give my answer to all of this and you tell me if you agree.

We examine the successes of ourselves and the people we admire, try to understand why they worked that time, and in what circumstances they would not work, and we capture this.

I think it should be clear, though it often isn't, that the reason we document patterns isn't all that zen, really.

It's to repeat other people's success, and allow them to repeat ours.

-- TimOttinger

JimCoplien wrote,

: A definition is a tool, and we use tools as they work. Definitions may be O.K. for someone who wants cocktail party familiarity with patterns (or who wants to sprinkle the word in a methodology book) but I don't think you can appreciate patterns from a definition, any more than you can appreciate a good painting or a good book from the Webster definition of "art."
: When people come to me, and they want to understand patterns, I often give them advice that Kent taught me to give them: go and write some patterns. Struggle with the forces. Struggle with what you really know that is really valuable. Assemble some patterns into a pattern language. Talk to some patterns folks and other designers about what you're doing along the way.

Before people "want to understand patterns", they first necessarily acquire a "cocktail party familiarity with patterns" that entices them to pursue the interest further. I don't see how this step can be skipped. It behooves us to provide some good definitions to launch this process for newcomers. To advise people to "go and write some patterns", with little sense of what they're striving for, yields results like the example Dick Gabriel gave:

: Problem: How do you allocate objects in memory?
: Context: A large OO system in a virtual memory computer.
: Solution: Run some typical problems and figure out which objects communicate frequently in a time locale and put them on the same page.
: This is not a pattern. It is merely a solution to a problem in a context.

Clearly, that definition is too terse and fails to provide enough guidance to point new folks in a proper direction. Below, I have attempted a roll-up of key issues mentioned in several prior postings, along with some wordsmithing:

: As a structural element, each pattern illuminates a compelling relationship among a given context, a specified system of forces that recurs in the context, and a proven software configuration that resolves these forces.
: As a language element, each pattern instructs how to reuse the software configuration to resolve the specified system of forces within the given context.

Compressing the above into a minimal (but not too minimal) sound bite:

: A pattern relates a system of forces recurring within a context to a proven software configuration that resolves them.

I don't think this can be boiled down any further: to use the words "problem" and "solution" is too vague regarding the desired focus of what a pattern is, and leads to examples like the one above.

-- DanielCooper?

DirkRiehle and Heinz Zullighoven give a pattern definition which I've become quite fond of. It was published in TAPOS in their paper "Understanding and Using Patterns in Software Development":

: A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts.

I like this definition because it is very faithful to the dictionary definition, and because it also applies to what we mean by "pattern" in contexts like this particular wiki page. The above authors point out that, within the software patterns community, the notion of a pattern is "geared toward solving problems in design." More specifically, the concrete form which recurs is that of a solution to a recurring problem.

But a pattern is more than just a battle-proven solution to a recurring problem. The problem occurs within a certain context, and in the presence of numerous competing concerns. The proposed solution involves some kind of structure which balances these concerns, or "forces", in the manner most appropriate for the given context. Using the pattern form, the description of the solution tries to capture the essential insight which it embodies, so that others may learn from it, and make use of it in similar situations. The pattern is also given a name, which serves as a conceptual handle, to facilitate discussing the pattern and the jewel of information it represents.

JohnVlissides wrote an article for his "Pattern Hatching" column in the March '97 CppReport entitled "Patterns: The Top Ten Misconceptions" (See PatternsMisconceptions also John's book PatternHatching). At the top of his list is the following (part of this will be strikingly similar to something Cope wrote above):

: Misconception 1: "A pattern is a solution to a problem in a context."
: This is one of Christopher Alexander's definitions, and calling it a misconception will be heresy to some. But a simple counterexample will make its deficiency clear: Problem: How do I redeem my winning lottery ticket before it expires? Context: The dog ate the ticket an hour before the deadline. Solution: Cut the dog open, fish out the ticket, and run to the nearest redemption station.
: This is a solution to a problem in a context. It is not a pattern. What's missing? At least three things: 1) Recurrence, which makes the solution relevant in situations outside the immediate one; 2)Teaching, which gives you the understanding to tailor the solution to your variant of the problem (most of the teaching in real patterns lies in the description and resolution of forces, and/or the consequences of application); and 3) A name by which to refer to the pattern.
: To be sure, a satisfactory definition has proven elusive, as witnessed by the on-going debate in the pattern-discussion mailing list. Contributing to the difficulty is the fact that a pattern is both a thing and a description of similar things. One way to differentiate the two is to use the term "pattern" consistently to refer to the description of the thing, and use "pattern instance" to refer to a concrete application of a pattern.
: Now, defining terms may prove a futile exercise, because a definition that's meaningful to one audience (say, programmers) might be totally meaningless to another (say, executives holding the purse strings). So I won't try to come up with the ultimate definition here. Suffice to say, any definition that stipulates a pattern's constituent parts must talk about recurrence, teaching, and naming in addition to problem, solution, and context.

After reading the above, I took it upon myself to try and come up with a short, one sentence definition to meet the above criteria. I wanted it to cover the constituent parts John describes while still remaining somewhat faithful to the oft quoted one-line definition cited from Alexander's writings. Here is what I came up with:

: A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces.

The above sentence seems to cover the requisite ingredients. It sure is "clunky" though (and long winded too). If I try to say it aloud, I almost pass out from loss of breath. I hereby submit the above as the longest single-sentence pattern definition which genuinely attempted (and failed) to be clear and concise :-)

Then I tried to shorten it up a bit and came up with:

: A pattern is a named nugget of insight that conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns.

This isn't particularly good (I like the previous one better, even if it is unreasonably long). It's not bad for using with beginners though (but nowhere near as good as some the other definitions on this page). Whenever I try to explain to a beginner what a pattern is (in 25 words or less), I typically start off by calling it a kind of "recurring best practice". That seems to get the ball rolling in the right direction.

-- BradAppleton

Maybe a simple but important aspect of Christopher Alexanders pattern concept has been lost in all these definitions and discussions.

: "A pattern is an object that is a proven solution to a problem in a context."

Although I never read a book of ChristopherAlexander, he very clearly talks about "elements of the world" and obviously seeks for the OrderOfNature by developing an universal theory of interacting objects (elements, centers).

The dog and ticket example is not a pattern because of the reasons given above, but simply because the solution is no object.

There are quite a number of pages in this wiki that describe good and proven solutions to problems. The authors themselves are uncertain whether they have found patterns or not and they are right, because they describe procedures and not objects.

-- HelmutLeitner

(continued in MorePatternDefinitionThread)

CategoryPattern