I'm often asked, "What is a pattern?" To those who are making only idle inquiries, I'll usually respond, A solution to a problem in a context.
To the serious, I usually avoid a direct answer and send them on their own ZenBuddhism-like journey in search of an answer.
This piece from RichardGabriel, posted to patterns-discussion on 8 December 1996, comes closest to a closed form description that will point people in the right direction to understand patterns. Note that I did not say that it is a definition; I don't think definitions cut it for those who seriously want to understand.
-- JimCoplien
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 it 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.
(Hmm.)
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 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 TimelessWayOfHacking?"]
--
RichardGabriel
I was having this discussion just yesterday with a client/partner. It seemed to us that describing a pattern within a context creates a template. That is, the template is the application of a pattern to a context. Thusly, the Publisher pattern can have a Magazine template, a Newsletter template, a DailyNewspaper template, etc. Now, how do we define the pattern thing again?
See: PatternDefinitionThread, ProcessAndaThing, TimelessWayOfHacking?