Pattern Hatching
P
LUGGABLE
F
ACTORY
, Part I
John Vlissides
C++ Report, November–December 1998
1998 by John Vlissides. All rights reserved.
Last time I introduced the concept of composite design patterns—patterns that document synergies between
other patterns.
1
I also promised to offer up examples of such patterns over several columns. I’ll start mak-
ing good on that promise beginning with P
LUGGABLE
F
ACTORY
.
Before doing that, though, I’d very much like to propose an alternative name for these beasties. Recall that
Dirk Riehle coined “composite design pattern” to refer to assemblages of patterns as distinct from the indi-
visible patterns we’re familiar with. He chose “composite” partly because he felt it was the OOP term of
choice for aggregations of things, be they objects, domain models, components—whatever. An informal
straw poll confirmed his intuition. But several of those polled also expressed concern over a potential am-
biguity.
What’s in a name?
One thing I’ve learned over the years is the value of pattern names as an aid to communication, especially
verbal communication. Alas, when you say “composite pattern” out loud, a listener can’t tell whether you’re
referring to a particular pattern, namely C
OMPOSITE
, or to a composition of patterns. The distinction is both
crucial and context-dependent, making it an impediment to clear expression. And an unnecessary impedi-
ment at that; choose something other than “composite” to denote pattern compositions, and the ambiguity
evaporates.
Many alternatives have been proposed, including “aggregate patterns,” “combination patterns,” “compound
patterns,” “pattern teams,” and “pattern ensembles.” I like “compound patterns” best, for three reasons.
Most importantly, it’s a natural usage of the term “compound.” You don’t have to be clairvoyant to infer
what’s intended. Second, “compound” avoids ambiguity, since there are no widely cited patterns by that
name.
The third reason isn’t a particularly good one, but I have to be honest: “compound” has nostalgic value for
me. Table 1 shows an early attempt to categorize the design patterns that appeared in our original paper on
the topic.
2
The attempt is so early, in fact, that you probably won’t recognize some of the names: “Wrap-
per” became D
ECORATOR
, “Glue” became F
ACADE
, “Solitaire” became S
INGLETON
, and “Walker” became
V
ISITOR
. You may notice a few more unfamiliar names, like “characterization” and “jurisdiction.” These
were provisional terms for what we ended up calling “purpose” and “scope” in Design Patterns.
3
Purpose classifies what a pattern does. For as long as I can remember, there have been three kinds of pur-
pose: creational, structural, and behavioral. Creational patterns abstract the instantiation process, whereas
structural patterns focus on how classes or objects are put together, and behavioral patterns tell you how
they work together. Meanwhile, scope suggests the domain over which a design pattern applies. Patterns
with class scope focus on static relationships, which mostly means inheritance. Patterns involving more
dynamic relationships are classified under object scope.
That, in a nutshell, is all there is to this classification scheme today. But once upon a time there was a third
kind of scope—you guessed it, compound. It was meant to distinguish recursive relationships from static or
dynamic ones. Most patterns so branded had something to do with traversal, which in C++ is commonly
implemented using recursion. Only Wrapper (D
ECORATOR
) didn’t involve traversal; it was recursive in the
sense that decorators can decorate other decorators, ad infinitum. Under this definition, classifying Walker
(V
ISITOR
) as a compound pattern was presumably a gaffe, or at least a stretch, because a pure visitor doesn’t