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 ProtoPattern''''''s 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. ProtoPattern''''''s, 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 ProtoPattern''''''s. 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 ProtoPattern''''''s 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 ProtoPattern''''''s. 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. ProtoPattern''''''s 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 PatternComponent''''''s. -- 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: * Each pattern is a kind of AbstractPattern. * Each AbstractPattern has an attribute called its PatternContext that contains an AbstractPattern. * A LivePattern is an AbstractPattern that has the QualityWithoutaName. * A DeadPattern is an AbstractPattern that lacks the QualityWithoutaName. * A ComposedPattern is an AbstractPattern that is comprised of AbstractPatterns (though I purposely leave the meaning of "comprised of" vague). * A PrimitivePattern is an AbstractPattern for which no component patterns have been identified. * The PatternContext of a LivePattern is always a LivePattern. This means that an AbstractPattern can only become a LivePattern if its PatternContext is also a LivePattern. * There exists some PatternContextContext, whose PatternContext is itself, and which is a LivePattern (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 AbstractPattern descendents: * PatternPractice: An AbstractPattern together with its PatternContext. * NeoPractice: A PatternPractice that has been UsedNoTimes. * ProtoPractice: A PatternPractice that has been UsedOneTime. * ProvenPractice: A PatternPractice that has been UsedManyTimes. 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 ProtoPattern''''''s 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 ProtoPattern''''''s do not have the same form as patterns. Perhaps relevant additions and subtractions must be made to the ProtoPattern''''''s concept? In fact, the concept itself may be a pattern --UmarSyyid ---- See ArchitectsOnBlueprints, PatternProposals ---- CategoryPattern