How do you know when to use the PatternForm
to describe a particular solution/problem/forces relationship? If there is a particular principle or problem/solution pair that can be documented, when is pattern form appropriate?
For instance, ChangeOfSetting
describes a problem, has a context and forces involved, and suggests a solution. But should it be a pattern? As another example, consider the principle-pattern WhatYouProduceTheyConsume
. Is this a pattern, or just a principle or idea in pattern form?
Maybe there are (or should be) definitive criteria for concepts suited for pattern form. What do you think?
See also: PatternFormsTakeSomeGettingUsedTo
A criterion based on the number for significant forces
at play may be a good starting point. Here's a first
If A then do X
To balance f(A, B, C, ...) do X
There's nothing to balance in the first two cases, so
the "solution" can be stated simply.
The third case benefits from using a pattern form,
particularly in describing the forces and their interplay.
call the second level
single-loop learning, the pattern level, double-loop learning,
and they describe a further level called TripleLoopLearning
. (More thoughts there)
I would suggest this checklist to determine whether
something is well-suited to pattern form:
- It must be a solution to a problem in a context
- You must be able to tell the problem solver what to do, how to solve the problem
- It must be a mature, proven solution (RuleOfThree)
- It must contribute to human comfort or quality of life
- It must be something you didn't invent yourself (BuschmannsLaw)
- The solution should build on the insight of the problem solver, and can be implemented a million times without ever being the same twice
- It cannot be formalized or automated (if it can be formalized or automated, then do that instead of writing it as a pattern)
- It should have a dense set of interacting forces that are independent of the forces in other patterns
Writing a pattern should probably be hard; if it's too easy
to write, it may not be a pattern, or you haven't thought
hard enough about the forces.
I think your points are either to strict or too much inspired by the original architecture pattern ideas of ChristopherAlexander
. Especially "human comfort or quality of life" and "a million times without being the same twice" will hardly apply to any software pattern. -- HelmutLeitner
Also, you can use the Pattern form
without writing a Pattern. I call these things Resolutions for lack of a better name. They resolve
the forces. They mainly differ from Patterns in that they aren't patterns
; that is, the three (or whatever) examples are missing. -- SunirShah
See also IdeaForm.
I thought about this overnight, and came back to add
some thoughts, only to find that Cope had not only
hit most of my meager additions,
but had also significantly raised the level of discourse.
Wiki is indeed a wondrous place...
Coming at Patterns from SystemsThinking
, my bias is to
use patterns to capture descriptions of portions of
systems, the forces that play in those parts, and what
experience has shown about leveraging or balancing
the forces to achieve either growth or stability.
We're often unaware of the larger pictures (systems)
that we operate in, and patterns can help both to reveal
previously unknown forces, and to shed new light on the
significance of those forces. Or, to paraphrase Cope, the
pattern should lead to new insights about the dense
interacting forces within the context.
A criterion that I wonder about is simulatability.
It should be possible to simulate, if not predict,
the outcome of applying
the pattern in a given situation.
Inability to simulate may suggest that either there are
forces in the context that are yet to be described
(i.e., the pattern is incomplete), or that the proposed
solution isn't amenable to pattern form.
Consider Alexander's patterns: many can be simulated
by building scale models.
Cope's final bullet is
problematic, since it is often difficult or impossible
to separate or isolate a subsystem from its larger system.
or to manipulate the subsystem without causing ripples.
I think that it's enough for the pattern to suggest what
those ripples might be, and to refer the reader
to related patterns.
"Although patterns have great value, not every plan
should be elevated to pattern status. First, many
plans are idiosyncratic to a problem domain or specific
solution. The true value in a pattern lies in its
many problems. Second, many
plans represent simple semantic-syntactic knowledge
and should thus be considered a part of the core
knowledge about the domain of software development all
developers should share. The concept of a subroutine
is not a "pattern" for solving a range of problems.
It is instead a core piece of knowledge required for
effective use of almost any programming language.
Third, it does not make economic sense to expand
the effort to 'patternize' every plan inside our head;
the payback is simply not there. Finally, the existence
of a pattern solving a problem only has value if you
know it! I'm not yet convinced the best strategy for
problem solving is searching through hundreds or
thousands of patterns in search of the
meeting the exact requirements of the problem." [p. 7]
takes time to learn. I find that a lot of core knowledge goes unnamed. But I also find that attaching a good name to a piece of knowledge helps me to remember it, which helps me eventually come to own
it. Ofcourse, having names also makes it easier to communicate with others. So perhaps these folks who are writing patterns that aren't actually patterns are really just trying to describe a new vocabulary? -- JoshuaKerievsky
I think you're definitely on to something Josh. Its still too fuzzy for
me to articulate though. Id love to see you expand on it if you have the time and the inclination. -- BradAppleton
Thanks for the encouragement Brad. I've actually made some good progress on articulating these ideas (and others related to the form of knowledge) in a pattern language I'm writing. I hope to have a version of it out in a month or two.
I would define Core Knowledge as the recognized basic patterns (Core Patterns) you aquire when learning. For example, the patterns of what a person looks like, what is a circle, etc. are core knowledge to the human race, but you probably aren't born with that knowledge either. A child is still taught these core patterns and everything they do in life builds upon them -- WyattMatthews