A Proto Pattern is a "wanna-be" pattern. It is something documented in a pattern form, but lacks supporting known uses. (Also see: Safe Loop, Buck Stops Here)
Finding those gems of "good" code, "good" design, or "good" whatever (see the Quality Withouta Name) is what Pattern Mining is all about. Sometimes you think you have discovered a "new" pattern, which really means that it is so-far undocumented. According to the Rule Of Three, a pattern must be Used Three Times before it can really be called a "pattern". (Validation Through Implementation)
With a Proto Pattern 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 Proto Patterns 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 Proto Pattern needs.
Proto Patterns, 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 Proto Patterns. Some safeguard must be in place so that the readers do not believe that they are Proven Practice before they really are Proven Practice. I believe that this means that we must label Proto Patterns as such, clearly and unambiguously.
A pattern that has not been Used Three Times, or does not have any Proven Practice, should always be labeled and called a Proto Pattern.
I am starting to think that most of what we call Patterns are really Proto Patterns. 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 Proven Practice and then move on?
What if the Proven Practice is really Bad Proven Practice?
-- Todd Coram (not trying to start another argument).
No argument here! I agree that there are probably many patterns out there documenting current Bad Proven Practice. 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.
Proto Patterns can serve as a first-step. Since there is no Proven Practice, 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 Proto Pattern 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 Pattern Components.
-- Dave Harris
My reading of Christopher Alexander (and Douglas Hofstadter) 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:
Each pattern is a kind of Abstract Pattern.
Each Abstract Pattern has an attribute called its Pattern Context that contains an Abstract Pattern.
A Live Pattern is an Abstract Pattern that has the Quality Withouta Name.
A Dead Pattern is an Abstract Pattern that lacks the Quality Withouta Name.
A Composed Pattern is an Abstract Pattern that is comprised of Abstract Patterns (though I purposely leave the meaning of "comprised of" vague).
A Primitive Pattern is an Abstract Pattern for which no component patterns have been identified.
The Pattern Context of a Live Pattern is always a Live Pattern. This means that an Abstract Pattern can only become a Live Pattern if its Pattern Context is also a Live Pattern.
There exists some Pattern Context Context, whose Pattern Context is itself, and which is a Live Pattern (by construction). My intent here is to mirror the loop at the top of the Smalltalk metaclass hierarchy.
In the context of this heuristic, I would describe a related family of Abstract Pattern descendents:
Pattern Practice: An Abstract Pattern together with its Pattern Context.
Neo Practice: A Pattern Practice that has been Used No Times.
Proto Practice: A Pattern Practice that has been Used One Time.
Proven Practice: A Pattern Practice that has been Used Many Times.
Since every Pattern Practice includes both the pattern and its Pattern Context, any Proven Practice with Pattern A and Pattern Context B becomes a Neo Practice when either A or B is changed to C.
Within this framework, any Pattern Practice (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 Anti Pattern, as described by Jim Coplien (and referenced above by Kiel Hodges), might be a Pattern Practice that can be shown not to work with ANY Pattern Context.
I chose Used Many Times instead of Used Three Times because I'm not sure that there's any magic in "three"...there's another pattern here in Wiki [(Two Is An Impossible Number)] that talks about counting as "zero, one, many".
I hope I've captured the spirit of Todd Coram's point here: A Proven Practice 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 Pattern Context is itself an Abstract Pattern (either composed or primitive), a Pattern Context of an existing good Proven Practice might change if someone discovers a subpattern of one of its Primitive Pattern components (and every Abstract Pattern must have at least ONE Primitive Pattern).
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...
an Anti Pattern... might be a Pattern Practice that can be shown not to work with ANY Pattern Context.
Some Patterns in Anti Pattern have been described as
sometimes an Anti Pattern.
(Cargo Cult is an example.) I think I prefer that something be one or the other or neither, but not both! --Kiel Hodges
Can the Proto Patterns concept be used more then just as a Pattern Wanna Be?
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 Unified Modeling Language. However UML, like blueprints, does not in my opinion capture the rationale or the "why" aspect of things. Maybe the Proto Pattern concept can be used to supplement the "blue prints" we use to create software.
Perhaps Proto Patterns do not have the same form as patterns. Perhaps relevant additions and subtractions must be made to the Proto Patterns concept? In fact, the concept itself may be a pattern --Umar Syyid
See original on c2.com 