Giving a pattern a single word for it's name is an AntiPattern
that create conflicts.
Using a single name for a pattern pollutes our vocabulary. Programmers often deal with words used and abused beyond their non-programming definitions. We lose the word twice when a pattern asserts rights over an existing word. We lose it once from it's English definition, and then again as a programming term.
Once a word is overloaded, the pattern will become overloaded. The ProxyPattern
lacks a strict definition beyond what the English word "proxy" implies. The proxy pattern may have had a specific programming meaning in the pas, but it has become generic enough to lose that meaning, leaving only the abstract meaning of the word "proxy".
The problem is compounded when named patterns are tied to a methodology, particularly ObjectOrientedProgramming
. The AdapterPattern
implies "adapting" a data structure to another. However strict definitions of the pattern state that it is for converting class interfaces - something missing from many programming languages. The pattern is unusable outside of it's OOP context, or is general enough to not need a specific definition when the English word suffices.
Patterns can have multiple names. One common pattern is the BigBallOfMud
, also known as TheBlob
. Both are essentially the same thing: a large chunk of heavily intertwingled code that is difficult to refactor or modularize. The wiki-style pattern (BigBallOfMud
) is preferable since the name implies the meaning, with little danger of naming conflicts. "Blob" asserts ownership over one word. If someone said "he's using the blob pattern" - it can have three meanings: A reference to the movie implying code that absorbs other code into itself, TheBlob
pattern, or an SQL Binary Large Object. Instead of simplifying, the naming compression distorts the issue and requires clarification. If someone said "he's using the BigBallOfMud
pattern", there is no conflict.
Consider a new pattern called "LlamaPattern
". One group decides the LlamaPattern
describes a class "with a long neck" - meaning it has a long inheritance tree. Then another group decides the LlamaPattern
describes defaulting to using the PerlLanguage
(from the O'Reilly book). Neither definition is inherently more valid, so there is little benefit to "compressing" the definitions into one word. Subjective compression of patterns into a disputed word leads to a land-grab situation with the English language. A better technique is to name the pattern according to what it is instead of using a metaphor. "LongInheritanceTree?
" or "DefaultsToPerl?
" are superior alternatives. For many reasons, there should never be a single LlamaPattern
Proponents of patterns and pattern naming state that a pattern is formalized after three occurrences. However three times is a completely arbitrary number, reflecting not the power of the pattern, but an abstract perceived notion of how popular the pattern (the concept, not the word) is. Every word in the English language is a potential programming pattern, and the "three times" metric is better left to witchcraft than programming methodology.
If every word is potentially a pattern, it questions the need for recording patterns at all. There are good reasons to record patterns though, as many abstract concepts do recur frequently. A good example is the excellently named BufferOverflow
is self-describing, has no conflicts with other meanings, and is more stable than a single name such as "Sandbucket", or any other word implying a buffer that is too small. Patterns are useful, but only when they are well-named and do not conflict with other meanings.
Use Wiki-style naming for patterns to prevent conflicts. Wiki-style pattern names gain their power not from rote memorization, but from the combinatorial power of descriptive words.
This is not a critique of the patterns in the GangOfFour
patterns. It is a critique of the naming system used. It is the opinion of the author that the benefits of the GangOfFour
patterns are nearly cancelled by their misleading and over-asserting naming. One can take a ThreeStagesInJeetKuneDo
approach and state that the names of the patterns are irrelevant once the concepts are absorbed, but if the purpose of a pattern is to be conveyable to others, such an argument holds little weight.
See PatternDictionaryGame PatternInEverything PatternBacklash