Pattern Backlash

I have encountered a weird kind of PatternBacklash. When I talk to people about patterns and they don't know I'm involved, I often hear, "Oh, that patterns stuff, what a bunch of hype." When pressed, though, they can't come up with a single instance of real hype. That is, nobody is saying, "This will solve all your problems." I think it's just that people are overloaded and they are used to new things being bullshit (because they usually are). -- KentBeck

It seems to me that although the study of patterns has yielded some (I consider) very useful patterns which serve as a common vocabulary for describing concepts, there also seems to be an overzealous desire to find a PatternInEverything. -- RicardoClements

I've gained the impression that DesignPatterns violate OnceAndOnlyOnce. If you need to use a design-pattern often enough for it to become a 'pattern', it should be refactored into a single language statement just like every other 'pattern' you refactor. If you can't refactor the design-pattern due to language limitations or other constraints, you'll end up apply the same pattern, by hand, repeatedly (thus the name 'pattern'). Of course, given a TuringComplete language you can potentially refactor anything, but beware GreenspunsTenthRuleOfProgramming and the overhead required to refactor design patterns in any generic manner. The need for DesignPatterns should be considered a LanguageSmell. A language that has a lot of DesignPatterns smells a great deal worse than one that requires only a few. DesignPatternsAreMissingLanguageFeatures.

The pattern stuff can be surrounded by an aura of mysticism, which I find off-putting. Several pages here make more or less explicit reference to Zen, ancient Chinese poetry and the like.

"Solving problems" I can understand. When you rephrase it as "resolving forces", you introduce a barrier to comprehension. You have to explain what "force" means in this context, and you get into rather artistic and mystical ideas about balance.

If you are dealing with someone who believes that "religion is fine as long as it doesn't interfere with my private life", then you need to show how this different terminology adds value. -- DaveHarris

You're right that there is no need for mysticism to explain this stuff. It is important that the forces bearing on a design problem be completely resolved without resorting to compromise. Compromises don't have the staying power common to patterns. -- WardCunningham

I recall reading a beautiful little takeoff on patterns that JimCoplien wrote, called KansasCityAirConditioner, or something, because I can't find it now and I'd like to link it in here. Just because it is repeatedly hot in Kansas and you resolve various forces by installing air conditioners doesn't make Kansas air conditioners a powerful pattern. It raises that nasty little question of when is it an Idea in pattern shape, and when is it a pattern with what Ward just called staying power? That's part of the pattern backlash. -- AlistairCockburn

I've tried to impose (on myself) a more careful definition of what I mean by "Pattern", especially in the context of software development.

I like to use the term "code" to mean the arrangement of classes and methods that comprise a program. BrianCantwellSmith? called this the StructuralField? of a process.

The code always has a CodeDesign?, although sometimes the CodeDesign? is ad-hoc. Especially for "simple" code, the same CodeDesign? can be expressed in Java, Smalltalk, C++, or for that matter any sufficiently powerful language.

I've discovered that CodeDesign?(s) often recur, and in fact there is a design that describes each CodeDesign?. This design-of-a-design is what I mean when I talk about a DesignPattern.

Finally, there is a parallel and related idea, which I'm still trying to formulate, that plays on the use of the term "Pattern" in the sense that a dressmaker or cabinet maker uses the word: a template from which to construct copies.

If you're in the HVAC business in Kansas City, I bet that KansasCityAirConditioner is a pattern (in both senses of the word), and I suspect it has enough "staying power" to feed a family for the foreseeable future, which is all you probably care about <grin>. As you move farther from that context, it probably works less and less well.

Alexander observed somewhere in Volume 1 or 2 (I don't have time to find it now) that the space between the shops and the street serves well as a street cafe in Europe, and doesn't work nearly as well for the same purpose in Los Angeles. I don't think that that means that "Street Cafe" is a pattern with limited staying power, I think it means that every pattern lives in a fabric of related patterns that provide a context for it. Put a pattern in an inappropriate context, and it dies. KansasCityAirConditioner probably doesn't live well in northern Maine. -- TomStambaugh

KansasCityAirConditioner is as much a pattern as Alexander's pattern for placing open air meeting areas relative to buildings. Designing a building so that a patio faces the sun in a cold part of the world and faces away from the sun in a hot part of the world makes sense. But, where I work you have to factor in occassional 50 mph winds from the North West as well as blazing sun (360 days of the year) from the South. -- DickBotting

I want to find a good word for the non-Alexanderian patterns: patterns in the dictionary sense: structural descriptions. To me, it is a shame that the word pattern has been co-opted to indicate a problem/solution pair with criteria for use. While I think that is very valuable, I know that there is much more that can be done, such as discovering the essence of various patterns to formulate a transformational grammar of modeling. The two approaches are not mutually exclusive. I think that people who can deal with the abstraction would be well served by the grammatical approach, and others who prefer to hunt through a catalog for their specific problem would be served by the others. The only downside with the "forces" approach is that there may be structural features in one pattern which would serve as a solution for problems with other "forces." Without a hunt you'd never find them. Taxonomy is a real issue as well. How do you find the one special thing that you need? Dealing directly with structure, an architect can generate a wide variety of possible structures based on transformations, but s/he is left unguided about the appropriateness of their use.

Regarding the Kansas air conditioners. I wonder if the pattern would be considered better if it was place independent. That is, the force is high temperature rather than arbitrary location. Also, I suppose the pattern would be more profound if it did not deal with the most common solution. For instance, if it were "breezeways for high temperature buildings" it might be considered better because of its educational value. -- MichaelFeathers

See also: IdeaForm

Regarding the existence of pattern "hype", the fact that there are books being written about patterns can be considered to be hype. I like the pattern books myself, but I've heard others ask why we need books to explain various ways of connecting objects and iterating over collections. Many patterns discussed in the books are "obvious" to experienced people, and they don't understand the utility of examining such patterns in excruciating detail. And I agree with the points about mysticism raised above: the creation of terminology, philosophy, and "religion" around patterns is another kind of hype. -- KrisJohnson

Unless a terminology is standardized and published you can not reasonably talk about it and it makes it very hard to teach or learn. In interviews I ask "How you can you reduce inter module dependencies?" As a response, I should get back more than 5+ strategies. Instead usually I get a lot of silence. This and many other topics are something people should know and be able to talk about as general concepts. People should be able to say "I have this problem what are my options for solving it?" Without codifying knowledge we can't do this. Imagine a medical profession that didn't standardize on body part names. Imagine if chemicals didn't have standard names. Programming needs this level of standardization and we have quite a number of ideas that can be teased out from craft and made common. This is all patterns are. -- AnonymousDonor

See PatternsFormBasisForaProfession

--- It was due in part to some academic studies that tried to quantify a process that is as much art as science.

LukeSamaha

(This was added from a refactoring operation.)

Some suggest that patterns are a sign that your abstractions are not strong enough because one is duplicating the pattern instead of referencing it, or at least that GOF patterns are not compact or concise enough. Some also suggest they are targeted toward, or only useful to C++ and the C-derived family. Most of the criticism seems to come from the scripting, Functional, and relational quarters.

In software engineering, duplication of something is often considered a sign that more abstraction or factoring is needed. Duplication should generally be refactored into one or fewer spots to simplify the code and localize changes to one or fewer spots (OnceAndOnlyOnce). In other words, why do patterns have to be duplicated instead of just referenced for each usage? Do GOF patterns represent unnecessary duplication? Is all duplication bad? Interesting philosophical questions.

http://www.paulgraham.com/icad.html

http://www.geocities.com/tablizer/prpats.htm#formulas

http://www.mail-archive.com/haskell@haskell.org/msg11907.html

http://norvig.com/design-patterns/

http://www.ai.mit.edu/~gregs/ref-dyn-patterns.html

"Do GOF patterns represent unnecessary duplication?" Take a look at RubyLanguage. Here is a singleton:

 class MyClass
     include Singleton
 end

No unnecessary duplication!

I always love reading Paul Graham's stuff, although he's a SmugLispWeenie and Topmind's stuff is always entertaining, however misguided. I think most arguments against patterns and GOF in particular entirely miss the point. Just today (12/05/02) RobertMartin writes in comp.object:

Like it [the GangOfFour book] or not, you'd better know it. The patterns in that book, and in many others like it, have become part of the vocabulary of our craft. Being unfamiliar with that vocabulary, and with the design patterns behind the vocabulary, will put you at a distinct disadvantage in a programming team.

And that's it right there. Patterns are just part of our craft. Who cares if Lisp users don't need them. We huddled masses of mainstream programmers still benefit. -- AndrewQueisser

{But couldn't the vocabulary start shaping, and limiting people's thinking? I agree that we need vocabulary to communicate, but it may also start shaping one's thinking about how to reason and analyze something. It reminds me how some naive individuals mistake "object" in OOP to mean something physical or visual, like a GUI icon or button. I suppose such is not fully preventable, but then just think of this as a warning to keep in mind.}

The vocabulary certainly shapes peoples thinking but it goes both ways. In the case of patterns, at least for me, what happened was that patterns gave a name to the structures I've found or used in C++. Now, if someone comes along and tells me that Factories aren't needed in Smalltalk or Lisp it makes a lot more sense than when someone comes along and says "In Smalltalk classes are objects." I can now appreciate the advantages of Smalltalk (although I still won't get to use it much) better than before. And I bet all those smug weenies started out writing code in C/assembly/whatever before they saw the light. Pain is a good teacher. -- AndrewQueisser

On a related note I wonder when will be the right time to pull the plug on C++. I don't mean replacing it with Lisp, Scheme, Java, C#, or Smalltalk; IMO they won't be able to replace C++ in its niches. But we already have decent imperative languages with stack, objects, parametric polymorphism (like Ada'95 and Modula-3). I was once (early 90's) proud that I knew C++, and studying more of it was a pleasure. Now, I'm not so sure anymore if I wasn't one of the vectors spreading the disease.

The last straw was read the recent discussion on templates, extern and separate compilations where I read from expert James Kanze that there are 4 different models of (source code)/compilation and users need to be aware of them. One might argue that all kinds of templated goodies are only "pour les connaisseurs" and the little software engineer need not be concerned. Until one hits the puzzling link and compilation conflicts between third party modules. I can understand that a little pain can teach you good lessons, but I'm afraid that C++ is pushing my limits too much.

Is this just me or there are others sharing my concerns? -- CostinCozianu

I think there are many, many people that share your concerns but I'm not one of them. Having grown into C++ from C over a course of 10 years I feel very comfortable with C++ but I don't use all of its features. I recently learned Ruby and like it very much. I'd recommend something like Ruby or SmallTalk to learn OO but I think it won't be time to pull the plug on C++ until the James Kanze's of this world have retired. this should be moved to a C++ page -- AndrewQueisser

"Example is not the main thing in influencing others. It is the only thing." -- AlbertSchweitzer? (1875 - 1965)

Unfortunately, the GangOfFour was originally cast in the lexicon of SmalltalkLanguage. At this point in history, Smalltalk is a footnote in the annals of computer language/environments. And through guilt-by-association, that "pattern stuff" has taken on the cultist patina of Smalltalk. Too bad. Compare this to TheArtOfTheMetaObjectProtocol. A great book, but cast in the language of LispLanguage. Not a lot of takers there. This is a strange comparison. TAOTMP is a great book, yes, but the *idea* of a MOP requires a language and object system as powerful as lisps. The mainstream languages aren't even close, and other languages with this sort of power are even less mainstream than lisp...

Have you read the GoF book? Most of the examples in it were in CeePlusPlus, not SmalltalkLanguage. The first language-specific treatment of the GoF patterns was in Smalltalk (DesignPatternsSmalltalkCompanion) because the book wasn't in Smalltalk.

Now people are looking to language-specific treatments of GangOfFour patterns. For JavaLanguage users, it is too bad that the mainstream SUN offering is abysmal. As more and more language-specific treatments of GoF become available, people will "take to" patterns because the examples that they can relate to are finally there. -- PeterConnolly Side note: The book HeadFirstDesignPatterns presents about 2/3rds of the GangOfFour DesignPatterns in JavaLanguage.

Maybe we should apply patent-like standards to software patterns. "Obvious" and "common" solutions are knocked above; perhaps a programming approach needs to be non-obvious and uncommon before it strikes us as a Software Pattern. (Though, in contrast to patents, the GangOfFour and others demand some prior art.)

On the other hand, if we want people to DoTheSimplestThingThatCouldPossiblyWork, maybe we should do the opposite. Maybe we should make sure we describe the obvious and common solutions to encourage their use when they are, in fact, simpler. If only the least obvious solutions, and probably the most complex ones, are elevated to the status of DesignPatterns, we'll have people drooling over them and wanting to use them even when it's not appropriate. (See also PatternsDocumentTheObvious.)

You've never whistled down a hall at work hearing " ... the manager proxy pool encapsulates composite visitor behaviour ...". Rubbish!

Actually, I have heard people many, many times talking in terms of patterns. What I haven't heard is your gibberish above, I wonder if you have any understanding of patterns at all.

Patterns take something simple and create great opportunity for those weakest to create complexity. Rubbish!

"Rubbish!" right back at you. Patterns do not create complexity any more than text editors do; if you inappropriately use a pattern then it will indeed make code unnecessarily complex but this will occur with any bad design whether patterns are involved or not. Use of patterns where they fit has no effect on complexity at all. One benefit that is gained from using patterns is the shared vocabulary which you claim is not used. Perhaps, with what little respect you are due, in addition to having no real experience with patterns, you have never worked with anyone who does, which is why you have never seen how useful it is to be able to say a few words and gain a 90% understanding of a design instantly rather than spending two hours or thousands of words to get to the same point. There are rational arguments against the use of patterns, your attempt is not one of them. And to your use of the term "weakest": judge not lest ye be judged.

CategoryPattern