Design Patterns Considered Harmful

It's a question, not a statement: Design Patterns Considered Harmful?

Perhaps this should be delete-merged with PatternBacklash

When I think back over the kinds of design I've seen, it separates down into three categories:

Hacked-together. Hard to follow, hard to change, eventually dies under its own weight.
OverDesigned. Hard to understand, hard to change, calcifies over time.
Simple and minimalistic. Easy to understand, easy to change, seems to get more flexible over time.

A special case of the "over-designed" category is the "patterns top-heavy" system. I've seen more of those recently, and I've also seen wider blind adoption of the GangOfFour DesignPatternsBook as the one and only True Way Of Program Design.

In struggling with one of the pattern top-heavy systems recently, I started to wonder: are DesignPatterns as valuable as the programming community thinks they are? In the beginning, perhaps, they were a valuable way to share insights about programming. But now that the AverageProgrammer has been told that the GangOfFour book is a bible, and embraced it accordingly, are we seeing the results we want? Or are we seeing blind uses of patterns in inappropriate ways? (cough)SingletonPattern(cough)

My question: Is the widespread adoption of design patterns harmful? Would we be better off de-emphasizing patterns, and instead describing characteristics of GoodDesign, forces that impact designs, and how to refactor one design into another? I think we would.

-- JimLittle

Define GoodDesign. Are patterns not designed well? How would you teach someone to design a particular system that had no idea how to do it?

The standard implementation is not always the right one; the reasoning behind the implementation is much more important. There are zillions of ways to implement patterns, and the amount of energy spent devising new versions of (say) VisitorPattern, for instance, would perhaps be better spent expounding design rationale.
"I used a visitor here"; VisitorPattern or Conjuror is not important. Why visitor is more important, I'd rather know your design forces. Something like Visitor can be used as a hack because you don't want to change the classes, to add new roles and other reasons. And sometimes it is best to just go ahead and modify the damn classes.
DesignPatterns don't always make good analysis tools, even about purely implementation problems. For example, I'd rather know that you thought there was too much coupling here, so you solved it using the FacadePattern.
The use of pattern names as some shibboleth granting access to a Pattern Gilead, forgetting deeper principles like coupling, cohesion, or even non-oo methods. You care not about patterns or even objects in themselves, just for code that works and makes sense.
Too much flexibility in a design can be harmful. It makes for too many ways to modify the code. The implementation may become slow and hard to understand. Indirection can clog compilers and CPU pipelines as well.

Complete agreement on communication of why rather than what.
Surely inflexibility in design is worse. Better to err on the side of flexibility. Objects are inherently flexible, and EmbraceChange is the ExtremeWay.

Flexibility gained by refactoring is different from attempts to build it in beforehand; this violates YouArentGonnaNeedIt. (See also RefactorOrDesign, RefactoringToPatterns.)

If "other people" aren't disciplined enough to program properly, they'll screw things up with or without design flexibility. Improve them or remove them. -- RonJeffries

If the alternative to an idiot using a pattern is that the idiot will try to invent something, I'll take the pattern. -- RonJeffries

Hahaha. Seconded -- AamodSane

No doubt this will prove a controversial topic. I've noticed some people seem to have an almost religious fervor for design patterns.

I share your view that GangOfFour DesignPatterns encourage OverEngineering, providing flexibility that isn't needed now and possibly never will be (YouArentGonnaNeedIt). Far better to KeepItSimple and use design patterns only when there is a benefit to be had now.

-- DavidPeterson

Having a description of many DesignPatterns in GangOfFour and promoting their use does not encourage OverEngineering at all. Patterns do not encourage providing flexibility that is not warranted. They merely show you some good ways to achieve that flexibility where it is warranted.

You can only teach people how to do something. You can't teach good taste. You probably can't even directly teach self-restraint. You certainly can't teach aptitude. But you can promote skill and knowledge. Denigrating -- or even merely discouraging -- one element of good programming will not help anyone. You need to push people to go further, learn more. One cannot merely study GangOfFour and be a good programmer, although that is a nice step on the road to Goodness for those who have the aptitude to understand GoF well.

The sort of people who hold one book as a bible, and don't analytically synthesize that book's content with other ideas and disciplines, will produce crappy software regardless of which book they choose. But if they absorb the ideas of (for example) GangOfFour, MartinFowler's RefactoringImprovingTheDesignOfExistingCode, and YouArentGonnaNeedIt from EmbraceChange, and they weave those ideas into a cohesive gestalt, they will probably not frequently misapply the ideas from those books. If they continue reading, even just one book every month or so that doesn't have 21 days, Definitive, Understanding, Mastering, Instant, or Dummies in the title, they'll probably become pretty good. (See also FooOneOhOneInSevenDaysForDummiesInaNutshellSuperBibleUnleashed.)

The problem is not that the programming masses are finally studying GangOfFour and DesignPatterns. The problem is that they do not go far enough in their studies. Don't discourage design patterns -- encourage further study.

"I've noticed some people seem to have an almost religious fervor for design patterns." "But now that the AverageProgrammer has been told that the GangOfFour book is a bible...": Of course the DesignPatternsBook is a bible! AddisonWesley encourages thinking of it as a bible by including a ribbon bookmark in the binding. The RefactoringBook is also a beribboned bible. There may be others as well. ;->

TestDrivenDesignAndPatterns talks about the proper use of design patterns.

Here's my fanciful explanation of the process of understanding Patterns, but I'm not a master, so I'm guessing.

Often the Pattern novice will spend the next month at work writing the GangOfFour patterns into everything, even where they don't belong. I know I did. I have this cauliflower shaped UML diagram to show for it. This will familiarize yourself with what patterns are.

Once this is done, some will graduate to journeymen. You will only use the GangOfFour patterns idiomatically. Maybe you'll read other patterns and mine some of your own. You'll start applying variations of the patterns you've read. This process familiarizes you with how patterns work.

Finally, some might become masters. A master will no longer use patterns except where they would occur naturally. After all, this is really what patterns are, the natural solution to the problem that have repeatedly arisen even before they were written. Sure, she will read more patterns, but only to understand the elegance behind them, not to memorize their structure. She might write more patterns too, but to describe the elegance.

I could be wrong, but the point is many people are novices. They just use patterns for everything because they don't know how to program. Some have stopped doing this, and have returned to a more selective approach. This characterizes most programmers who have a lot of experience solving programs. Very few really grok programming well enough to consistently find the natural solutions to problems, and perhaps no one does. -- SunirShah

To see the pattern for this take a look at WittgensteinsLadder.

The problem I have with patterns is that I've seen programs of people who obviously think: "The more DesignPatterns I use, the better is the design." I think that's what Sunir means above with novices. And I did that too. -- ThomasHolenstein?

Given the choice between such people, and those who seem to think: "The more classes I define, the more object-oriented (and thus better since ObjectOrientation is a MagicBullet) is the design," I will certainly prefer the former. -- KarlKnechtel

See PatternDensity

Having been introduced to Patterns just recently, within 2 1/2 years, I can look back and quite vividly point out the time where I thought everything should be programmed to a pattern. Now, however, I mostly use patterns for team communication. It's a very important and efficient communication tool for designing systems. Whether we end up using a pattern to solve a solution or not, we were able to quickly come to a consensus on a design because of the similar level of pattern knowledge.

Please have a look at SoftwareDevelopmentMagazine and read the article "Stop Over-Engineering" by JoshuaKerievsky. ( http://www.sdmagazine.com/documents/s=7032/sdm0204b/0204b.htm ) It's a very nice article and the author talks about not introducing DesignPatterns up front but instead of RefactoringToPatterns when needed. -- PeterAxelsson

I was first introduced to a similar concept in ObjectOrientedDesignHeuristics (Chapter 10), where Arthur Riel speaks of what he calls "transformation patterns". His suggestion was to use the design heuristics to determine when to transform a design from one pattern to another. -- PatrickOShaughnessey

I often use the VisitorPattern, not as a pattern, but as a red flag to simplify. Ever since I read the darned thing, I've wanted to use it somewhere. Quite often now, when I'm trying to resolve a complicated issue of communication between two objects, I find myself wondering whether I can apply the visitor pattern here. Usually, I take that as a cue that the communication is too complicated to begin with.

So far, I've never actually implemented the VisitorPattern. The more times I don't implement it, the more valuable it is to me. :) -- PhilGroce

I see patterns as being analogous to martial arts forms. The forms serve to preserve and pass on fighting techniques, and to demonstrate how those techniques work together. Practicing the forms correctly leads to insight into the techniques and gets the body used to moving in ways that hopefully make the person a better fighter. However, when you find yourself in an actual fight to defend yourself from bodily harm, if you go into one of your forms you'll get your butt kicked.

Patterns should be used the same way. They serve to pass on the experience of other programmers. Study them, practice them, learn their essence, then forget them. When you program, do the simplest thing that works. With the experience and insight you gained by studying the patterns you should be better able to see the simplest solution.

That's how I see it, anyway. -- JasonArhart (See also MartialArtsAsSoftwareDevelopmentMetaphor)

I guess it was inevitable that a site that was started to discuss patterns (i.e., this wiki) would eventually spawn a page called DesignPatternsConsideredHarmful. To me, it is a naive question. It would be like starting a page called FoodConsideredHarmful?. Almost anything you can ingest (including water) is lethal if you abuse it.

Patterns are a form of compression. By identifying a little it implies a lot. Much of which may not be known. Learn from other people's experiences too. I'm glad my house is being built with standard components. Refactoring the .4 x .78 can be expensive.

I'm not too sure that this analogy really applies here. It's one thing to build a system using open standards, defacto standards, existing components and existing APIs etc. etc.

As discussions go this is one very relevant more for the non-believers, the novice, who should understand that no defined abstraction should be taken as the final word. I have always read the GangOfFour book as a guideline to healthy programming style, though some of the patterns can be used as they are. At least a novice should use all the DesignPatterns as they are initially, then modify his approach as he masters the concept and application. It is like not "reinventing the wheel" when you use the patterns intelligently, but at the same time have the sense not to use it as a "thumb rule" applying it with abandon even if it does not fit efficiently. -- Sudhakar Krishnamachari

Please explain "OverDesigned. Hard to understand, hard to change, calcifies over time." Particularly the "calcifies" part.

Anecdote:

I used to work on maintaining a large (in codebase) CeePlusPlus application that was designed by people who were completely wild about patterns and insisted on their use at every turn. This particular system made extensive use of layers and factories. So much in fact that individual layers consisted of multiple layers and all communication between just about anything (and especially between those 9 (that was the number I think) layers) had to go through special objects. No object could be created except through a factory (often a special factory just for that object). That's overdesign. Design with no perspective on the implementation of the design.

Finding where to apply changes to get something specific done often took more time than the actual change (I know, documentation. But how many projects have you worked on where the documentation was 1) adequate, 2) up to date and 3) there at all?). Due to the incredible number of object constructions and method calls needed to get the simplest thing done, simple operations often took inordinate amounts of time. As a result some things HAD to be hacked in out of the design in order to get needed performance (building a printing routine that skipped most layers to directly access the database access layer instead of going through all the proxies led to 1000 pages being printed in an hour instead of taking 3 days for example). That's your hard to change (and also why ultimately the design fails as the people maintaining and expanding the application go outside the design in order to get the required results).

We were afraid to touch some parts of the code because we couldn't figure out what they did and why. As a result such code doesn't get maintained and when new functionality could in theory reuse it with maybe minor changes to make it more flexible it was rewritten from scratch. That's calcification of code.

Thank you. That is exactly what I was talking about. Have we worked on the same projects? :) -- JimLittle

Another way of putting the gripe may be that patterns have become a major source of GoldPlating since the GangOfFour book trickled down. At least, that's my observation.

Patterns are definitely misused/overused - and I think that it is largely an effect of developers being driven into taking shortcuts. Too many times I've seen them go directly to the "solution", ignoring both the initial context and the resulting context. They forget (if they ever knew) that in assessing any design solution it is necessary to decide if applying it makes things better or worse. This assessment depends both on the solution and on the context in which it is applied.

The popular GangOfFour DesignPatternsBook could have done more to discourage this by putting the patterns in the context of a design process. But most of the problem is the readers who skip to "the meat" and, through fascination with the clever "solutions", lose the principal benefit of patterns: they describe how the solution changes the design context. -- AlanGriffiths

Patterns are not the problem. The problem is when to apply them. The DesignPatternsBook argues in favor of determining the patterns at a paper design stage (i.e., BigDesignUpFront). This leads to many of the woes described above. If, however, you follow DoTheSimplestThingThatCouldPossiblyWork and only apply patterns when the design asks for them, patterns become a very powerful tool. Some times the simplest solution is to use a concept that has already been proven in other implementations.

I work with a development lead who uses the term "pattern" to describe any code he wants other people to copy and paste. His rationale is that once he has got it working everyone can benefit from following his "design pattern". He uses CopyAndPasteReuse as his primary reuse strategy and inheritance where code duplication becomes too overt.

Maybe this kind of misconception about patterns is one of the reasons they are sometimes derided. In general though I agree with most of what is said here: patterns are useful as solutions to particular problems, but when it's appropriate to use them depends on a genuine understanding of the needs of the system. -- BenArnold

In my experience, patterns are better communication tools than design tools. It is far easier to explain a class in your design as a Singleton than a "class that controls the number of instances of itself". But using it as a design tool is very dangerous and SingletonPattern is an excellent example. It is easy to understand, so most modern projects are filled with Singletons. Literally, there are hundreds of them in every medium scale project. I mean, if it is really that prevalent, it should just become a language feature! (See also AreDesignPatternsMissingLanguageFeatures.)

The problem arises, I think, because people understand the structure and functioning of a pattern easily but neglect the consequences, which are the most important part, IMHO. The GangOfFour book never claims that the patterns are a panacea. They can be used only when the forces are right. And even then, there will be tradeoffs and consequences. Not understanding them is what leads to abuse of patterns. (See also PatternAbuse.)

-- SriramGopalan

A pattern is tool. Any fool who can misuse a tool will do so. Now in fact even the much maligned goto is not harmful if its only used when it should be-- that is never. So now what do we do-- hide all the tools? I am of the opinion that ours is an industry of fads, which is unfortunate. I have seen paradigm of the week mentality, mostly in management,but often enough the technical staff who will learn soon enough to parrot back buzzwords in exchange for a cracker ( or a paycheck). In fact, they will use patterns not as tools of thought, but as substitutes for thought just like the well worn cliches they pass about in their memos-- they are safe, they are easy, and no one ever got fired for buying IBM or building an MVC via a Singleton proxy over a decorator. ( I really hope that no such thing exists-- I was trying to put patterns together at random. If does exist my apologies if you think I was making light of your design.)

How do you get programmers and managers to really understand Patterns and what they are for? I think you start with " No Silver Bullet" by Fredrick P. Brooks. If they can't get that there is no point going further. It is the quest for the "silver bullet" that drives even the well intentioned to the misuse of the latest tool, never mind those who have another agenda.

MarcGrundfest

CategoryPattern CategoryConsideredHarmful CategoryDesign