"Once upon a time, we wrote a book called A Pattern Language and that is how we got our name. Now, a pattern is an old idea. The new idea in the book was to organize implicit knowledge about how people solve recurring problems when they go about building things. "
Christopher Alexander
What is a software pattern?
How do writers about software patterns decide what software artifacts are patterns? How do these writers decide what patterns are worthy of note?
Christopher Alexander is the writer most associated with originating the idea of a pattern as a design concept.1 As the above quotation makes clear patterns are about making explicit solutions to recurring problems that people have created.
So a pattern formalizes knowledge that the profession has already arrived at.
Alexander never defined the word pattern. Nothing wrong with that. In fact the whole idea that we should define all our terms before we use them is misguided. The best definitions emerge from discussion and debate. Relying on people's intuitive notions on what a pattern is, is better than trying to spend time defining what a pattern is. In fact philosophy has long realized that good definitions arrive over time and debate. 2
My dictionary has various definitions for pattern. To use "a model for making things" seems to be the most useful stake in the ground to start the discussion.
In other words, a pattern is not just a solution to a problem. It is an abstraction of a solution that can generate several possible implementations. This of course, corresponds to Alexander's use of the word. His patterns such as "agricultural valleys" or "house for one person" do not have one possible implementation.
So a good software pattern is not a software technology. Hence WS* and REST are not patterns. They are implementations of a standard.3 The standards operate the same way on different platforms. This is no different than a mold for a cup being used to cast a bronze or sliver cup.
Given this point of view, a looping construct is not a pattern. A linked list is not a pattern. What about file systems? Anybody who remembers JCL realizes that there is more than one way to work with disk sectors.
But don't looping constructs come in several flavors? Aren't they different ways to solve the problem of control of software programs. Way back in the early days of computing people had to come up with these various ways of handling control flow. They were not divine revelations; that had to be invented. Anybody who remembers the arguments over the use of "goto"s , whether programs should have single or multiple entry and endpoints, or whether co-routines were a good idea might think of all of these as control flow patterns.
It is just that we take them for granted now that we might not consider them as patterns, just as technological givens. So patterns do need a context. Whenever somebody discusses patterns you need to clarify the domain of discourse. There are certainly patterns in certain "application domains" such as "double-entry" bookkeeping in accounting.
In fact looping constructs, assignment constructs and the like perhaps should be considered patterns once again. The rise of multi-processors, and distributed computing force us to think once again about what it means to do an assignment statement. In a distributed environment, where there is a latency in updating the value of any value, saying "x=y" is not always simple.
Whenever you discuss patterns, you must state the context in which you are talking. A pattern in one context could be a foundational technology in another context.
- http://www.patternlanguage.com/leveltwo/caframe.htm?/leveltwo/../bios/douglea.htm
- http://www.sfu.ca/philosophy/swartz/definitions.htm
- The OAIS reference model for SOA (http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf) would consider WS* and REST as implementations.