Proto Pattern
Proto PatternA 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.
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:
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
EditText of this page
(last edited February 17, 2009)
or FindPage with title or text search