is a "wanna-be" pattern. It is something documented in a pattern form, but lacks supporting known uses. (Also see:
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
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
(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
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.
Sometimes it can help merely to identify potential PatternComponent
My reading of ChristopherAlexander
) 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?
- 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...
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
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.
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