Patterns Misconceptions

This page is dedicated to identifying and clearing up these common PatternsMisconceptions. Please contribute to it so we may better help others to understand not only what patterns are, but also what patterns are not.

--BradAppleton

Excuse me, but is there any evidence supporting the existence of most of these "misconceptions"? With all due respect to John, I feel that a large part of the article was a fishing trip to reach the magic number 10. -- StevenBlack

Fair enough, Steven. I wish I had a neat citation for each misconception, but I don't. They arose from interactions with many people over the past four or five years in real and virtual settings, including newsgroups, mailing lists, e-mail, tutorials, seminars, consulting, and one-on-one. I had more than 10 candidates when I sat down to write the article, but I cut them down to ten for effect. They're the "top ten" in the sense that I felt I had heard them more than the others. --JohnVlissides

The following misconceptions are from JohnVlissides article in the March 1997 issue of the Object Magazine titled: "Patterns: The Top Ten Misconceptions." A revised and updated rendition appears in Chapter 1 of PatternHatching.

Misconception 1: "A pattern is a SolutionToAproblemInAcontext."

This is an oft-quoted definition used for brevity. But it's a bit too brief. It misses two or three critical elements that all patterns must have:

• Recurrence : The solution to the problem must be one which successfully recurs in known systems
• Teaching : The solution must be described in a generative manner. It can't just describe the solution passively, it must teach you how to (re)construct it.
• Name : The solution must have a name which serves as a "conceptual handle" to facilitate its discussion.
• Variation : A pattern without variation is just a cookbook. Patterns come into their own when there is a certain "sameness" that emerges from superficial difference.

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

Vlissides calls this the belittling dismissal whereby one tries to "reduce something unfamiliar to something known, especially if you're not motivated to investigate the unfamiliar."

Also: expect the folk who jump on bandwaggons to manage to bluff their way among folk who don't grok patterns by managing to exhibit the symptoms listed ... such folk will be peddling all the misconceptions and will create disillusionment among others because, when scrutinised closely, the `patterns' they're using are, indeed, just jargon, rules, tricks and etc.

Misconception 3: "All patterns are created equal"

[Renamed "Seen one, seen them all" in PatternHatching]

Patterns can be used to solve recurring problems of all shapes and sizes from a wide variety of domains. They vary in granularity (architectural vs idioms) and can be as different as their many authors. A set of related patterns don't need to all have the same size/significance, they each need only to help you further along toward your desired goal. Whether they take a giant leap or a baby step, each pattern has its rightful place in achieving the overall solution.

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

The main benefits of patterns are as follows (none of which requires any tool support or methodology of any kind):

1. Patterns capture expertise, making it accessible to non-experts

2. Pattern names form a shared vocabulary which promotes more effective communication among designers.

3. Patterns increase the ease/time to understand a system when it documents the patterns used.

4. Patterns facilitate restructuring a system (even if it wasn't design with those patterns in mind).

Patterns don't guarantee anything. They don't remove humans from the creative process. They do help humans engaged in the creative process by describing known solutions to common problems in the domain. They are another tool in the designer's toolbox, not a silver bullet!

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

Patterns don't generate anything - people do. Patterns help people generate whole architectures. What's more, patterns won't cover every aspect of a design. There will always be problems that no pattern addresses, either because they are not common enough or because no one has written up patterns for them yet. You will have to use your own creativity to fill the whitespace in a design.

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

The most well known book of patterns in the software community is the GangOfFour's DesignPatterns book. It catalogs 23 patterns of object-oriented design. The members of the GangOfFour will be among the first to tell you that there are plenty of other patterns besides patterns of (object-oriented) software design. There are many other recurring problems that need solving besides problems of software design and implementation, and there are many recurring solutions for some of these problems. Patterns about software process, organizational structure, analysis, testing, risk management, requirements management, change management, configuration management, quality assurance, tools and technology acquisition, and a whole slew of others.

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

Back when the hype first started, this may have been true. But this is no longer the case. There are numerous published reports (several with hard data) of benefits from using patterns in various professional/technical journals, books, and conference proceedings.

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

This seems to be a common misconception (and a fairly damaging one at that) but it's just not true. There are all kinds of people in the patterns community. Some of them like to wax philosophical about patterns theory and concepts, others prefer to be relentlessly pragmatic in their focus. Although there are many from academia in the so called "patterns community", the majority thus far seem to be from industry. There are all kinds of people in the patterns community and characterizing the entire community based-upon a few threads of discussion from a few individuals would be wildly inaccurate (and a grave injustice). The patterns community is as diverse as its membership. As John says, "The grassroots nature of the patterns community is clearly at odds with any insinuation of homogeneity and elitism."

Having said that, there are same basic tenets that many in the patterns community like to foster and adhere to. These tenets embody some of the essentials of professional responsibility, integrity, and utilitarianism. Take a look at PatternValueSystem.

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

Some of this results from backlash at a lot of the PatternHype, but few things could be further from the truth. John writes:

Now that "pattern" has achieved status, it's inevitable that some will leverage the term for less than altruistic purposes [the "TragedyOfTheCommons"]. 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.

Misconception: "Every new/good solution is a pattern."

If it's a pattern, then by definition, it can't be new. It has to be something which has successfully recurred in previous systems (preferably three times or more -- this is known as the "RuleOfThree").

Even if it's a good solution that has worked once, that's swell. But it's not a pattern until you can show it has worked more often than once.

Misconception: "Any solution written in PatternForm is a pattern."

Nope. First of all, it has to be a recurring solution. It has to possess all the other elements of a pattern as well. It needs to show you how to achieve the solution. Simply saying "do X" without saying what "X" is or how to go about doing it isn't very helpful (see, for example, KansasCityAirConditioner for a spoof of such a pattern).

One or more of the popular PatternForms may be useful for documenting solutions that haven't yet achieved pattern status (e.g. aren't yet known to recur). But lets all be responsible by explicitly stating they aren't yet known to be patterns (call them ProtoPatterns if you like).

Misconception: "Patterns are abstract principles/heuristics."

Not usually. Principles and heuristics are usually too abstract/generic to be patterns. A pattern abstracts the essentials of a recurring solution, but the solution is a very concrete one with a specific context. Principles (like "low coupling") and heuristics (like "add another level of indirection") are often the underpinnings of the forces and/or rationale of a pattern, but they are usually too general/universal to be patterns. A pattern often shows how best to apply one or more heuristics/principles in a given situation.

This does not mean principles and heuristics are somehow less important than patterns! We need good principles and heuristics every bit as much (perhaps even more) as we need good patterns that show us how to apply them in various contexts. Just because pattern is a popular buzzword at the moment doesn't in any way diminish the value and importance of principles, heuristics, or even of well-designed solutions which are not yet known to recur.

Patterns, principles, heuristics, and new solutions are all valuable tools in the designer's toolbox and each has their rightful place among the others.

Misconception: "Patterns are a silver bullet or panacea."

This is similar to the misconception that patterns can guarantee productivity, quality, world peace, etc. We should all know by now that there is no silver bullet. Anyone who tells you otherwise (about patterns or anything else) is either a snake oil salesmen, or has gotten too caught up in the hype and lost control of their faculties.

Even when used to solve the problem they are stated to address, a pattern is not guaranteed to solve the given problem outside of its stated context. This leads into our next misconception ....

Misconception: "Patterns are universally applicable."

Patterns come with a statement of their "context" or "applicability". The same problem may arise in many different contexts. Using a pattern in a context other than the one it describes might work out anyway, but never assume that it will nor that it should.

To me, patterns are a nice destination to strive for, but are often a lousy starting point. The problem lies in the fact that you don't know which you've hit until you start to try to plug a particular pattern in. I prefer to start with the simplest solution and refactor it back into a pattern if it fits. --JasonNocks

Certainly; understanding, thinking, design, and architecture should all be subject to refactoring, not just implementation.

This is on the part of OO pattern community. When they discover a good solution that becomes a pattern because it may be applicable in other contexts, pattern people write it in pattern form, declare it a pattern, publish it, prepare it for OOPSLA and so on, so forth.

But there's another view to it, coming from the functional programming community: patterns in code are bad (heard it several times at ICFP 2004). The OO pattern movement promotes informal patterns that generate patterns in code. Rather than have an informal description generate patterns in code, functional programmers will look for a formal programming language abstraction be ready to use by simple invocation. Examples: if you think you need to deploy the iterator pattern maybe a simple fold_left would be better ? if you need an abstract factory, maybe you should rather look at functions as first class values. See AreDesignPatternsMissingLanguageFeatures

Even better than patterns are: higher order functions, higher order modules, Lisp/Scheme macros or other language extensions, domain specific languages.

The current contributor (CostinCozianu) is ambivalent on this issue. I think functional programmers do have a very good point to make on this one. On the other hand, I am not convinced that is is desirable to eliminate all patterns in code trying to achieve an illusory CodeNormalForm? (more on this, maybe later). And there's also another delicate balance: by the time it takes my team to complete TheEvolutionOfaHaskellProgrammer, they can more easily grasp the DesignPatternsBook and finnish a couple of projects in the meantime. On the other hand, as IcfpProgrammingContest proves, a team of the right smug functional weenies can easily outperform any regular team in the industry by a one or two orders of magnitudes.

[Please feel free to correct any of the above "in place" and/or to dispell more patterns misconceptions here.]

This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006