Patterns: The Top Ten Misconceptions

John Vlissides

Along with all the hubbub these days about patterns comes more than a little confusion, consternation, and misinformation. This is partly a reflection of how new the field is to mainstream software developers (although it's not, strictly speaking, a new field). It's a fast-moving field too, which creates vacuums of facts. And yes, we pattern proponents deserve some of the blame for not educating people as thoroughly as we'd like, though not for lack of trying [Buschmann+96, Coplien96, Gamma+95, PLoPD95, PLoPD96].

This is my humble attempt at dispelling the more egregious misconceptions about patterns---misconceptions I've heard often enough to qualify as patterns in their own right. (I actually toyed with using a pattern form to articulate them. Then it dawned on me that reducing everything to patterns was itself a misconception!) Keep in mind that the opinions expressed herein are my own; I'm not speaking for the pattern community. I expect most pattern cognoscenti would agree that these are prevalent misconceptions, but I don't expect them to agree with how I dispel them. If all I do is start a dialog on these issues, I'll declare success.

Mulling over what I've heard people say about patterns over the years, the misconceptions seem to fall into three categories: misconceptions about what patterns are, about what they can do, and about the community that's been promoting them. Each of my "top ten" fall into one of these categories. So I'll organize them accordingly, looking first at misconceptions about what patterns are.

Misconception 1: "A pattern is a solution to a problem in a context"

Problem: How do I redeem my winning lottery ticket before it expires?

Context: The dog ate the ticket an hour before the deadline.

Solution: Cut the dog open, fish out the ticket, and run to the nearest redemption station.

1. Recurrence, which makes the solution relevant in situations outside the immediate one.
2. Teaching, which gives you the understanding to tailor the solution to your variant of the problem. Most of the teaching in real patterns lies in the description and resolution of forces, and/or the consequences of application.
3. A name by which to refer to the pattern.

At any rate, defining terms may prove a futile exercise, because a definition that's meaningful to one audience (say, programmers) might be totally meaningless to another (say, executives holding the purse strings). So I won't try to come up with the ultimate definition here. Suffice it to say any definition that stipulates a pattern's constituent parts must talk about recurrence, teaching, and naming in addition to problem, solution, and context.

Misconception 2: "Patterns are just jargon, rules, programming tricks, data structures...."

Now about those comparisons: There is in fact a pattern jargon---terms like "pattern" itself, "forces," Alexander's "quality without a name," and so forth---but patterns hardly reduce to jargon. Compared to most areas of computer science, patterns introduce comparatively few new terms. That's symptomatic, actually. A good pattern is intrinsically accessible to its audience. It may well use the jargon of its target domain, but there's rarely a need for pattern-specific terminology.

Neither are patterns rules you can apply mindlessly; the teaching component should counteract any such tendency. Nor are they limited to programming tricks, even though the "idioms" branch of the discipline focuses on patterns that are programming language-specific. The term "tricks" is a tad pejorative to my ear, and it overemphasizes solution at the expense of problem, context, teaching, and naming.

No doubt you've heard of an innovation's three stages of acceptance: first it's dismissed as rubbish, then it's merely nonviable, and finally it's obvious and trivial---"What we've done all along." Patterns aren't entirely out of stage 1 yet.

Misconception 3: "All patterns are created equal."

Misconception 4: "Patterns need tool or methodological support to be effective."

When I speak on this topic, I usually point out four main benefits of patterns:

1. They capture expertise and make it accessible to nonexperts.
2. Their names collectively form a vocabulary that helps developers communicate better.
3. They help people understand a system more quickly when it is documented with the patterns it uses.
4. They facilitate restructuring a system whether or not it was designed with patterns in mind.

In short, patterns are primarily food for the brain, not fodder for a tool. There may yet be latent benefit in methodological or automated support, but I'm convinced it'll be icing on the cake, not the cake itself or even a layer thereof.

The misconceptions I've looked at so far have to do with what patterns are. Now for a few misconceptions about what patterns can do. These come in two flavors: the overstating kind and the understating kind.

Misconception 5: "Patterns guarantee reusable software, higher productivity, world peace, etc."

People speak of good patterns producing an "Aha!" response. That can only occur if the pattern strikes a chord in the reader's mind. If it doesn't, then the pattern is like the proverbial tree that falls in the forest with no one around to hear it---did it fall? So it is with patterns: what good is a pattern, no matter how well written, if it doesn't produce a resonance in the human mind?

Patterns are just another weapon in the developer's arsenal. To ascribe much more to them is counterproductive. Underpromise and overdeliver---that's the best defense against hype and backlash.

Misconception 6: "Patterns 'generate' whole architectures."

The generative aspect of patterns gets discussed periodically in the pattern forums. As I understand it, generativity refers to a pattern's ability to create "emergent behavior." That's a fancy way of saying the pattern helps the reader solve problems that the pattern doesn't address explicitly. Some of what I've read suggests that true generativity makes this happen almost in spite of one's self.

To me, the key to generativity is in the parts of a pattern dedicated to teaching---the forces and their resolution, for example, or the discussion of consequences. These insights are particularly useful as you define and refine an architecture. But believing that patterns themselves can generate architectures or anything else is definitely over the top. Patterns don't generate anything; people do, and they do so only if both they and the patterns they use are up to snuff.

Misconception 7: "Patterns are for (object-oriented) design or implementation."

Patterns are nothing if they don't capture expertise. The nature of that expertise is left open to the pattern writer. Certainly there's expertise worth capturing in object-oriented software design, but there's just as much to be had in non-object-oriented design---and not just design but analysis, maintenance, testing, documentation, organizational structure, on and on. Patterns in these varied areas are now emerging: already there are at least two books on analysis patterns [Hay96, Fowler97], and each PLoP conference attracts new kinds of patterns. (A particularly interesting submission to the 1996 conference concerned patterns for music composition!)

Like most misconceptions, there's a grain of truth in this one. When you look at the pattern forms people use, you see variations on two basic styles: the highly structured GOF (Gang of Four) style used in Design Patterns, and the near-belletristic style of Christopher Alexander---narrative, with minimal structure. Having dabbled in pattern writing for something other than object-oriented design, I now recognize how biased the GOF style is toward its domain. It just plain doesn't work for other areas of expertise I've tried: What should the Structure diagram look like for a C++ idiom? The implementation trade-offs in a pattern for music composition? The Collaborations in a pattern for good expository writing?

Clearly, one pattern format does not fit all. What does fit all is the general concept of pattern as a vehicle for capturing and conveying expertise, whatever the field.

Misconception 8: "There's no evidence that patterns help anybody."

As time progresses, we'll get a better handle on the benefits (and pitfalls) of pattern usage. The initial returns are promising; we need more experience to fully assess the impact. It would be foolish indeed to reject patterns out of hand just because their performance remains to been measured.

So much for fallacies about what patterns can do. The last two misconceptions concern not patterns per se but the community that has championed them.

Misconception 9: "The pattern community is a clique of elites."

Given the pattern community's penchant for publishing, one might wonder at the relative paucity of academics. The fact is that the majority of people who attend PLoP are practitioners. It seems to have always been so. Not one of the prominent early proponents of software patterns---including Kent Beck, Ward Cunningham, and Peter Coad---comes from an academic background. Only one of the Gang of Four (Ralph) is from academia, and he's the most applied academic I know. The grass-roots nature of the pattern community is clearly at odds with any insinuation of homogeneity and elitism.

Misconception 10: "The pattern community is self-serving, even conspiratorial."

Poppycock!

Speaking as one of the Gang of Four, I can affirm that we were as surprised as anyone by the reaction to Design Patterns. Certainly none of us was ready for the feeding frenzy at its OOPSLA '94 debut---even the publisher was caught off-guard by the demand! Throughout the project our overriding concern was to create the highest-quality book we could. We were too busy just trying to understand this stuff to be distracted by sales issues.

That was then. Now that "pattern" has achieved buzzword status, it's inevitable that some will leverage the term for less than altruistic purposes. But if you read the works of leading pattern authors carefully, you'll sense a common and overarching desire: to take hard-earned expertise, best practices, even competitive advantage---the fruits of years of hands-on experience---and not just disclose it but impart it to all comers.

It is this passion for improving the reader's lot that motivates a sincere and effective pattern author. Anything less is self-defeating---and the ultimate misconception about patterns.

ACKNOWLEDGMENTS