Alex Davies

Software Engineer - Red Gate Software

Why following "Design Patterns" is a bad idea

Published Thursday, March 19, 2009 3:05 PM

When I first started work, my manager decided that it'd be a good idea to make sure I was well trained enough to design good code. That sounds fair enough. So I was given a book (or told to read a website, I can't remember) about design patterns. The "Gang of Four" was mentioned, which appears to be a popular book that concentrates on object-orientated languages.

I've been told to learn design patterns at least three times now, once at university, once at my summer job, and once here at Red Gate. Maybe they're some kind of background knowledge you need to be a really good programmer or something?

If you're not familiar with the majoy GoF design patterns already, I would encourage you to read about them. You'll probably like a lot of what they say and one day you might make a better design decision because of it.

But, don't get tempted to actually use any of them.

There are some fairly obvious reasons that you shouldn't try to apply a particular pattern all over the place in your code. Code which follows a pattern tends to spend more time talking and thinking about the pattern that it does about getting the job done. The only really valuable resource when programming is space for concepts inside the programmer's head. For this reason, whatever you do, don't use terminology from the pattern in your source. Make up new words. In the real world, all code is pretty much unique, and it's important to remind yourself that.

Another reason not to follow a pattern is to keep you as good a programmer as you are now. It's already too easy to get comfortable with an approach, and become unwilling to try another technique, without deliberately making all your code act the same. We need practice architecting, so when the next genuinely hard task comes along, or we move to another language, we have a hope.

In source code written by a variety of people, you can usually tell by the style which developer wrote it. A lot of that is the visual layout, but I also get a feeling of the mind behind the code (spanning from the feeling of peace and beauty I get from the view at the top of a mountain, to the wild fun of the mosh pit of a good rock band). That goes to show that no-one's capable of designing code "right" (least of all a bunch of guys who wrote a book 15 years ago). So I try to be the developer that can't be identified from their code, as I change the designs I use depending on what I think's best at the time.

I also specifically think some GoF design patters are actively bad. I'll tell you which at some point, but it's best to avoid them all for now just in case :)

Comments

 

RobertChipperfield said:

Agreed! Write something that does the job, not something that almost does the job and then has to be hacked in obscure ways to do the job you actually wanted to do.

I'm also tempted to say the same thing about a lot of Frameworks - they get you 90% of the way there very quickly, but I find the last 10% often takes longer than the whole thing would've done if you hadn't used it in the first place :-).
March 19, 2009 11:50 AM
 

Bart Read said:

Hmm... By "my manager" you'd better not mean me. I tried to read that GoF book once and nearly died of boredom. And the examples, such as they are, do not bear any resemblance to anything you might do in the real programming world. Some of them are useful (factory, for example), but the thing is, it doesn't take too long to work out that a lot of them look remarkably similar. I also have this rather cynical, and perhaps contentious, theory that people who wax lyrical about patterns a lot do so only because they can't code for toffee.
March 19, 2009 6:05 PM
 

Jason Haley said:

March 20, 2009 9:25 AM
 

Justin Trask said:

Sorry but I disagree with completely.  I never read the original gang of 4 book but I have read the Head First Design Patterns book and I refer to it frequently as do many other developers I have spoken to.  Where I work the requirements of some of these applications change every frequently and the successful implementation of a good design pattern makes these changes easier to handle.  
March 23, 2009 5:29 AM
 

SkyBeaver said:

I couldn't agree more!  There's an old saying, "when the only tool on your belt is a hammer, every problem tends to look a lot like a nail".  I go out of my way to avoid hiring any developer who appears to be a member of the "Design Patterns Hezbollah".  They seem to see EVERY problem in terms of some permutation of previously published design patterns.  And, as you say, they end up spending more time and energy on fitting the design pattern to the problem than they do the part of the code that actually implements the solution.

With that said, I do think that the myriad books on design patterns have also had a useful side effect on our industry.  If developers are encouraged to think about their code in terms of elegance, simplicity, and reusability, that is certainly a good thing.
March 24, 2009 11:58 AM
 

What can we learn from design patterns? « Joon’s software learnings & leanings said:

April 8, 2009 1:06 PM
 

JoonduRandt said:

I thought that this is an interesting viewpoint. It inspired the question "What can we learn from design patterns?"

And I have expanded on that though on my blog, here:
http://joondurandt.wordpress.com/2009/04/08/what-can-we-learn-from-design-patterns/
April 8, 2009 1:09 PM
 

Alex Davies said:

In my earlier post I mentioned that there are a couple of design patterns that I think are wholly wrong....
April 16, 2009 4:33 AM
 

BuggyFunBunny said:

Design patterns aren't necessarily a bad thing.  But they can turn into religion (pick your favorite human one for metaphor).  

There are two other books which I find more useful:
Allen Holub: Holub on Patterns: Learning Design Patterns by Looking at Code
Vadim Tropashko: SQL Design Patterns: Expert Guide to SQL Programming

Holub builds some non-trivial examples using design patterns, gives you (most of) the code, and a detailed description of the how and why.  Holub writes java, and is considered something of an outsider, since he has no patience with framework of the month programming.  He writes compilers in his spare time.

Tropashko takes some liberties with the phrase "design pattern", in that he covers some exotica (tending toward Oracle, since that is his native syntax) in kind of depth.  An interesting read, nonetheless, from the point of view of what might be consider design patterns in a database world.
April 20, 2009 9:27 AM
 

MrShaunWilson said:

I think wht most people tend to forget is that Design Patterns were never defined in order to instruct software engineers in how to do their job. Further, they were not intended as a pool of constructs by which you can piece together your next solution.

Rather, Design Patterns were defined so that we have a definition of common practices, a vacabulary of what we see every day, but perhaps have never formalized nor defined for what it is. A superb example is the Collection, a pattern developers of all walks have been intimately familiar with for a long time.

Years ago, I had an employee that would regularly come into my office and grab my GoF book and start flipping pages. I asked him what he was doing one time (out of curioisity, since I can't imagine anyone would really *need* to read a Design Patterns book *that* often) and he replied "I'm looking for some ideas," while I can't disagree with the idea of creative exposure, I have never heard a more absurd and sincere statement in my life.

I have since worked with a large number of people that treat Pattern books this way (as a source of creativity), and a smaller number of people who treat patterns as a religion (recently working with a guy that would blurt out every pattern he recognized, like it was a contest.)

Just remember the original intent: "Design Patterns" are a vocabulary we can use to describe, model and communicate Software Design. Nothing more.

October 30, 2009 12:01 AM
 

Stardust Motel Las Vegas, Vega Complete Whole Food Health Optimizer said:

May 20, 2010 5:44 PM
 

V40 Roof Rails Tempered Galvanized Steel, V400 Used Gsm 850 said:

May 20, 2010 11:52 PM
 

1999 Kia Sportage Owners Manual, 1999 Kia Sportage Issues Defects said:

May 21, 2010 4:27 AM
 

Venture Definition Capital Investments, Venture Lenders said:

May 21, 2010 5:16 AM
 

Mazda Mizer Replacement For Sale, Yahoo Minimizer said:

May 21, 2010 1:58 PM
 

Mystique Aftermarket Mercury Cougar, Headlight Auto Salvage 2002 Mercury Cougar said:

May 21, 2010 5:01 PM
 

Grand Mercure Park Avenue Agoda, Grand Prix Association Racing History said:

May 21, 2010 5:45 PM
 

93 Geo Prizm Timing Belt, 2000 Geo Prizm Body Kits said:

May 22, 2010 12:43 AM
 

450sel Heater 1988 Mercedes Benz, 450sel Buy Used Mercedes Benz said:

May 22, 2010 10:24 PM
 

Aries Spears Movie, Aries Toy Chest - 103.computeronlinebingo.com said:

May 22, 2010 11:39 PM
 

E 450 Super Duty Stripped Chassis Discount Vibration Dampener, E 450 Full Xd Picture Cards - 115.animejin.com said:

May 23, 2010 3:00 AM
 

Gran Torino Discount Magnum Force Actors, Replacement Magnum Mini Dodge Cb300 - 288.tvshowzone.com said:

May 23, 2010 4:23 AM
 

St Regis Auto Dodge Avenger, 1998 Dodge Avenger Parts Floor Mats Replacement - 498.mfbattle.com said:

May 23, 2010 5:25 AM
 

Mercedes Benz 280sel Radiator Auto Parts Cylinder Head, 280sel Find - 311.renters.ws said:

May 24, 2010 11:14 AM
 

S550 Auto Sl63 Amg, Ford E 550 Econoline Super Duty Headlight Assembly Bulbs Included Explorer Sport Trac - 255.rkwrh.com said:

May 25, 2010 3:58 AM
 

Executive Limousine Party Bus Rental Homes, Hyundai Accent Executive 2008 - 245.computeronlinebingo.com said:

May 25, 2010 4:21 AM
 

Chevy G1000 Episodes Replacement, Chevrolet G1000 Series Pt - 321.unlockiphone30.net said:

May 25, 2010 7:58 PM
 

Glc Space, Glc Manual Fog Light - 379.myipgirl.com said:

May 25, 2010 8:41 PM
You need to sign in to comment on this blog



















<March 2009>
SuMoTuWeThFrSa
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234
Raw Materials: Command-Line Nostalgia
 Arthur finds philosophy deep in a dialog box. Read more...

Increasing Email Size Limits for your High Profile Users in Exchange 2010
 If you ever need to set up fine-grained rules to control the maximum size of messages a subset of your... Read more...

Product Review: Schema Compare for Oracle
 One of the more important tasks in the process of rolling out incremental developments to a... Read more...

Implementing the OUTPUT Clause in SQL Server 2008
 In retrospect, it was probably the inclusion of the OUTPUT clause in the MERGE statement that gave... Read more...

SQL Source Control: The Development Story
 Often, there is a huge difference between software being easy to use, and easy to develop. When your... Read more...