Pattern Definition Thread

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."

Alexander writes:

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

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.

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.

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."]

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?

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?

"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

(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."

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.

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."

Definition 4. The proven one

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

- by RickAnderson?

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.

"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.

- by RichardGabriel

- from A Timeless Way of Hacking.

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

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

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).

• 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.

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.

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.

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.

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

-- 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.

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.

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.

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.

-- 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."

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)

This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006