A
ProtoPattern is a "wanna-be" pattern. It is something documented in a pattern form, but lacks supporting known uses. (Also see:
SafeLoop,
BuckStopsHere)
Finding those gems of "good" code, "good" design, or "good" whatever (see the
QualityWithoutaName) is what
PatternMining is all about. Sometimes you think you have discovered a "new" pattern, which really means that it is so-far undocumented. According to the
RuleOfThree, a pattern must be
UsedThreeTimes before it can really be called a "pattern". (
ValidationThroughImplementation)
With a
ProtoPattern you can document a concept in a pattern form, and be awaiting the blessing of at least two other uses before being canonized as a Pattern. These
ProtoPatterns may be published (like here on Wiki), where others may say "Yeah! I've done that before!" and thus provide the much needed use case support the
ProtoPattern needs.
ProtoPatterns, submitted for review in such a way, provide people not only with a means of documentation, but a channel for validation. Many simply don't have the depth of experience or time for supporting research to find those other known uses of the pattern.
The catch is that
everyone must agree that they are
ProtoPatterns. Some safeguard must be in place so that the readers do not believe that they are
ProvenPractice before they really are
ProvenPractice. I believe that this means that we must label
ProtoPatterns as such, clearly and unambiguously.
A pattern that has not been
UsedThreeTimes, or does not have any
ProvenPractice, should always be labeled and called a
ProtoPattern.
I am starting to think that most of what we call
Patterns are really
ProtoPatterns. Some software patterns may have been used dozens of times, but are still suspect. I tend to have more faith in organizational patterns (and programming idioms) than in software architecture/design patterns. Do we have enough success stories in our software architecture and design efforts to catalog them as Patterns, teach them as
ProvenPractice and then move on?
What if the
ProvenPractice is really
BadProvenPractice?
--
ToddCoram (not trying to start another argument).
No argument here! I agree that there are probably many patterns out there documenting current
BadProvenPractice. However, that is
still a pattern. Maybe this is another thing patterns can be used for: documenting current practice, not just to teach solutions, but to
re-evaluate the solutions.
ProtoPatterns can serve as a first-step. Since there is no
ProvenPractice, good or bad, it can go either way for the pattern. But at least there is a wider audience that can review or try the
ProtoPattern before it gets set in stone as a "good thing." This could cut down on the amount of "new" patterns that actually provide bad solutions.
--
DavidHooker
Sometimes it can help merely to identify potential
PatternComponents.
--
DaveHarris
My reading of
ChristopherAlexander (and
DouglasHofstadter) suggests that any putative pattern makes sense only in the context of another pattern. Could it be that when we use evaluative words like "good" and "bad", or debate "proven" versus "proto", we could be identifying differences in the
context of the alleged pattern in question?
In that spirit, let me offer a heuristic (perhaps someone can make it into a pattern...), as follows:
In the context of this heuristic, I would describe a related family of
AbstractPattern descendents:
Since every
PatternPractice includes both the pattern and its
PatternContext, any
ProvenPractice with Pattern A and
PatternContext B becomes a
NeoPractice when either A or B is changed to C.
Within this framework, any
PatternPractice (whether Neo, Proto, or Proven) can be described as bad if it fails to work and good if it works. I leave the definition of "work" as an exercise for the reader.
I think an
AntiPattern, as described by
JimCoplien (and referenced above by
KielHodges), might be a
PatternPractice that can be shown not to work with ANY
PatternContext.
I chose
UsedManyTimes instead of
UsedThreeTimes because I'm not sure that there's any magic in "three"...there's another pattern here in Wiki [(
TwoIsAnImpossibleNumber)] that talks about counting as "zero, one, many".
I hope I've captured the spirit of
ToddCoram's point here: A
ProvenPractice that has been demonstrated to work a large number of times
in certain contexts might still not work at all in other contexts.
Furthermore, since a
PatternContext is itself an
AbstractPattern (either composed or primitive), a
PatternContext of an existing good
ProvenPractice might change if someone discovers a subpattern of one of its
PrimitivePattern components (and every
AbstractPattern must have at least ONE
PrimitivePattern).
My intent in this last point is to emphasize that the good- or bad- ness of EVERY pattern can change, no matter how many times its been used, when someone identifies or discovers additional structure within itself or its context.
I hope this helps...
--
TomStambaugh
an AntiPattern... might be a PatternPractice that can be shown not to work with ANY PatternContext.
Some Patterns in
AntiPattern have been described as
sometimes an AntiPattern.
(
CargoCult is an example.) I think I prefer that something be one or the other or neither, but not both! --
KielHodges
Can the
ProtoPatterns concept be used more then just as a
PatternWannaBe?
One of the great advantages of using the patterns form has been certain parts of our designs now have a well explained rationale. We know what the "forces" are and how they affect the "particular solution". In short we know and write down much of the "why" of the design.
The comparison between building architecture and software architecture has also led to comparisons between blueprints and software modeling languages such as the
UnifiedModelingLanguage. However UML, like blueprints, does not in my opinion capture the rationale or the "why" aspect of things. Maybe the
ProtoPattern concept can be used to supplement the "blue prints" we use to create software.
Perhaps
ProtoPatterns do not have the same form as patterns. Perhaps relevant additions and subtractions must be made to the
ProtoPatterns concept? In fact, the concept itself may be a pattern --
UmarSyyid
See
ArchitectsOnBlueprints,
PatternProposals
CategoryPattern