programming and human factors
by Jeff Atwood
I'm beginning to wonder if the book Head First Design Patterns would be better titled Ass Backwards Design Patterns. Here are some quotes from pages 594 and 595 of this 629 page book:
First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not "how can I apply a pattern to this problem." Don't feel like you aren't a sophisticated developer if you don't use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern.No one ever talks about when to remove a pattern. You'd think it was blasphemy! Nah, we're all adults here, we can take it. So when do you remove a pattern? When your system has become complex and the flexibility you planned for isn't needed. In other words, when a simpler solution without the pattern would be better.
Design patterns are powerful, and it's easy to see all kinds of ways they can be used in your current designs. Developers naturally love to create beautiful architectures that are ready to take on change from all directions.
Resist the temptation. If you have a practical need to support change in a design today, go ahead and employ a pattern to handle that change. However, if the reason is only hypothetical, don't add the pattern. It's only going to add complexity to your system, and you might never need it.
Filling 593 pages with rah-rah pattern talk, and then tacking this critical guidance on at the end of the book is downright irresponsible. This advice should be in 72 point blinking Comic Sans on the very first page.
Beginning developers never met a pattern or an object they didn't like. Encouraging them to experiment with patterns is like throwing gasoline on a fire. And yet that's exactly what this book does. Page 597 outlines how therapeutic it is for beginners to abuse patterns:
The beginner uses patterns everywhere. This is good. The beginner gets lots of experience with and practice using patterns. The beginner also thinks, "The more patterns I use, the better the design." The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibility.
Do you really want a junior developer using patterns everywhere? It's about as safe as encouraging them to "experiment" with a gas-powered chainsaw. The best way to learn to write simple code is to write simple code! Patterns, like all forms of compexity, should be avoided until they are absolutely necessary. That's the first thing beginners need to learn. Not the last thing.
The book isn't the only thing that's backwards: did you know the Head First girl pictured on the front of the book leads a shocking double life? That's right, student by day, stripper by night. Ok, maybe not ...
... but shocking nonetheless. Perhaps they're referring to the code smell of overcomplicated "explosion at the pattern factory" code this book encourages?
Ban Comic Sans! [bancomicsans.com] It is an insult to centuries of typography. However, putting tags around that "font" is kind of fitting.
well, i'll offer up a good pattern book that likely isn't on the general radar:
Holub on Patterns: Learning Patterns by Looking at Code
for those not familiar, Allen Holub is an Olde Guy who got to java by way of C/C++ (yeah, not a .NET person). he hates beans and most uses of inheritance; on both points he is not alone, but most of the lemmings in the Apache crowd don't like him. feat not. this book has two (pretty much) complete, workable systems. one is a SQL interpreter. it is very dense going, but worth it.
robert on September 6, 2005 8:45 AMI find it very funny that you criticize the book, but you link to its Amazon page using your affiliate ID.
Ervin on September 6, 2005 8:49 AM"Patterns, like all forms of compexity, should be avoided until they are absolutely necessary. That's the first thing beginners need to learn. Not the last thing."
Yeah. And beginner will know for sure, when the usage of the pattern is absoulutely necessary and when not. Especially if they never tried that pattern before.
I think Kathy and Bert know a big deal about beginners and teaching, so I am not exactly sure what the point of this post was.
I didn't say the book was entirely without merit. I like the writing style, and it's a good overview of patterns.
That said, I feel very strongly this advice -- that patterns are complexity, and not to be used lightly -- should be presented up front, not 600 pages in..
Jeff Atwood on September 6, 2005 12:21 PMI think that it is funny that the same picture is being used for both materials. You have to assume that both "companies" got it from the same box of clipart/pictures. With that said, I wonder if the girl even knows where and when her picture is going to be used. She was probably paid $100 for the original picture and could end up on everything from condom boxes to bran flakes.
matt on September 6, 2005 1:40 PMGosh, I think you're being a bit harsh. Presumably someone who picks up the book does so to learn about patterns. The book teaches them (in its own way), and then warns you at the end not to overuse them. If you don't get that far in the book, you probably gave up on learning patterns from it.
I enjoyed it, and went on to GOF from here.
Stick in the mud on September 12, 2005 7:13 AMHey at least they put that disclaimer in, even if it was near the last page.
I agree though. Newbies shouldn't be using design patterns in production code anyway. they should be trying it out in some test code first and refactoring production code where its obvious that the design pattern will help, hopefully with the guidance of a more senior developer.
Fregas on October 10, 2005 6:31 AMSo and where should a junior developer begin? The GoF book? Or simply saying, don't use patterns because it's too complex? I've never heard of somebody telling unexperienced developers how to learn about patterns, but I've heard dozen's of them how NOT to do it. Whow, the experienced users have spoken...
Reinout on October 11, 2005 4:28 AMSo and where should a junior developer begin? The GoF book?
Start with DRY and KISS, with a little YAGNI thrown in for good measure. Don't believe me? Read the quotes from Linus Torvalds and Anders Hejlsberg:
http://www.codinghorror.com/blog/archives/000113.html
Once you feel you've mastered the art of writing simple, straightforward code, then and only then should you advance to patterns.
Jeff Atwood on October 11, 2005 7:42 AMMy vote is on The Pragmatic Programmer.
Yes, excellent recommendation. That, Code Complete, and Don't Make Me Think, would be the first books I'd recommend to a junior developer.
Jeff Atwood on August 4, 2006 10:14 AMI agree, junior developer armed with a pattern book is akin to a monkey with a hand grenade. At the very least, he'll blow up himself.
However, I am yet again suprised with the general perception of the complexity of patterns. For some reason, for most people pattern = complex. This is not true. Pattern is simply a solution for a particular problem that is known to work relatively well. The solution can be simple or complex, but the word "pattern" should not imply complexity per se.
Stas on August 5, 2006 3:12 AMI need some guidance. What exactly is programming? Is this regarding computer programming... or something a little, how shall I say, mindful programming.
Are you all robots?
Kaeli on October 8, 2006 8:20 AMOOP is a mess, and that is why it is hard to say anything solid about GOF design patterns. When, where, and why to use them is a can of worms. OOP is the modern-day GO TO. We need to borrow from Set Theory, not masses of object pointers. OOP should die, or at least shrink.
TomMinderson on November 12, 2006 9:37 AMcan anybody tell me two best design patterns?
mush mush on February 8, 2007 1:04 AMJeff, I'll have to agree with "stick in the mud" that perhaps you are, at least in tone, a bit harsh. I agree it would be a good idea to give some of their late advice a bit earlier. On the other hand, perhaps they felt that giving too many warnings too early would muddy the waters enough to scare "beginners" off, or, (gasp!) confuse them. People new to large-scale software development will be writing a lot of code - perhaps for the first time. That's why we hired them. I would say patterns are *not* complex - they encourage simplicity versus other horrible things people could/will do. We want the newbies writing lots of code to learn to use patterns.
Teaching about patterns in a decent, humorous way without scaring them off is probably a good idea. And winding up with some solid, practical advice is also a good idea, and a common pedagogical technique.
In the end, I think that people are more likely to actually read and understand this patterns book then many of the others out there. And that's the important thing!
Brian, I agree the presentation of the book is great. But I still think the advice may end up steering a lot of programmers in the wrong direction:
http://www.relevancellc.com/2007/5/17/design-patterns-are-code-smells
Jeff Atwood on May 22, 2007 10:32 AMA design pattern is just a tool. If it makes your job easier then use it (first you must know it exists) and if it doesn't, then don't.
Usually making our jobs easier means decreasing complexity. So patterns should be used only when they do that. So I don't agree that "patterns are complexity".
If you can take out that nail with your fingers don't be stupid and don't use a hammer. But if you can't use your fingers don't be stupid and use that hammer!!!
Daniel Cadenas on July 10, 2007 11:34 AMYeah, design patterns overuse can bring use in difficult situations, but not using them at all will create a big mess for sure.
oodesign on January 20, 2008 1:59 AMyuch - I HATE the presentation of that book and I refuse to buy it. I guess that just proves how old I am. I'm not saying that learning can't be fun, but I need something more than a MAD magazine approach to getting my attention. If a concept is difficult, then explain it to me without a picture of some idiot looking confused.
OK, I *AM* old. I also can't stand all the pictures of these "hip" kids who can't dress properly. Of course, I work form home so I'm not really dressed properly either unless casual day includes boxer shorts, t-shirt, and no shoes...
The popularity of this book really does highlight a growing generation gap between us older developers and the new twenty-somethings coming into the profession. (And I'm not really all that old...)
sick to my stomach on May 22, 2008 11:26 AMIn my opinion, the first Design Pattern they introduce in that book is Bridge Pattern. It is not Strategy Pattern as they wrote. However, the style of writing is funny and i like it. I think it's very easy for newbie to learn something about Design Pattern.
Regard your statements, I think to make our code simpler, the best way is using right Pattern. Therefore, I don't agree with your idea.
Nguyn Thoi on June 11, 2008 6:08 AMThe title geared toward beginners NOT Juior developers. It doesn't teach programming, OOP and slaps design pattern into the mix. Every developer, one point in time, will be a beginner to this topic. I think at that point the developer should have already graduated and know the basics of professional programming: writing clear, consice and well documented code.
The book is funny and keeps you entertained. Obviously after reading this book you should practice patterns on your own before applying them to production code. Nobody reads a tutorial/book on Threading and starts writing threading code all over their app (atleast I hope not!).
dumas on June 30, 2008 11:18 AMSo is learning patterns more complex than learning the reason behind patterns such as the GRASP/OO principles. Try to explain Low Coupling, High Cohesion, Pure Fabrication, Protected Variants etc etc etc to a junior developer. Or create the structure of code for a junior developer and explain we are using a Factory here, a strategy there or a composite over here. With a little knowledge of patterns they can then code within the framework of those patterns, and with a reference such as the above book gain an understanding of why. Create the class structure for them first time around if they are that green!
Using a pattern you do not need IMHO takes very little time extra in coding but probably make you think more about the structure initially which can never be bad. I have never seen a pattern that was not needed cause any other headaches for an application, so I completely fail to see the argument against.
Some developers hate to debug patterns because of the layers they inevitably create, but for me this is just the mind set and lack of knowledge, and probably because it is more interesting to create new code, and therein lies the problem I feel.
Its NOT the pattern that is complex but to identify the symptoms that derive your thinking towards applying the pattern. And frankly guys I haven't yet discovered a more simple way of implementing singleton. All patterns are already made simple (provided you're meeting the contextual requirements of them).
You apply the right pattern in right context, you enjoy the promised benefits. And if you apply the right pattern in the wrong context .. bang you made an Anti-Pattern.
I agree with Paul that one must go through learning the basic principles/reasons behind those patterns and only then move to learning patterns. Even though DPs can still be used as a cook book but you may have high probability of going to Anti-Patterns instead of Patterns.
muhammadallee on July 13, 2008 12:21 PMI disagree.
This book is on Design Patterns- intended for an audience of willing people who want to learn design patterns
The did give a disclaimer on how to use- which I think was excelent - IMHO correctly placed.
And I also disagree that this book is not for begginers
I think it services the OOP community well talking about OOP principles and patterns in a well written fashion
Like always such a fuckwit comment about design.
Charl on December 28, 2008 11:00 AMThat girl is still pretty hot even if she has plumbing issues. I would re-code her harddrive.
joe_chivas on January 21, 2009 3:04 AMJeff asks: Do you really want a junior developer using patterns everywhere?
Well, no. But neither do I want them using inheritance to solve every problem either.
I'm thrilled when I find newer programmers on my team studying up on DPs and OOP principles and this book does a fine job of it, taking that you don't mind their unique approach to teaching (DPs taking on personalities and arguing with each other, other DPs being interviewed by a reporter, etc).
Besides, the book starts off with the common problem of class explosion and deep inheritance trees and introduces a SIMPLE pattern to tackle the problem (DPs == complexity? Nonsense). Plus on page 29 (!!) it tells the reader that DPs shouldn't be shoved into your code ad hoc, but implanted in your brain so you can start thinking of better ways to author your software systems.
Newer programmers may certainly over-rely on DPs and force them into a solution that doesn't need them. So be it, us more experienced programmers are there to provide mentoring - are we not?
Sean on January 31, 2009 2:35 AMYou really shouldn't point out Linus Torvalds. IIRC, the guy is very against OOP, which isn't that surprising given his background. It's funny, because I think there are a fair amount of people who strongly warn against design patterns and overuse. My experience with these programmers is that they almost always use very little OOP in their own code. Furthermore, when requirements changes come along there's more rewriting than refactoring.
My advice is this: stop warning people against something that's vastly underused as a tool as it is. It's an easy metric that 9 out of 10 programmers have not heard of design patterns and think inheritance = OOP. Instead, keep the strong warnings for things like copy-and-paste programming, golden hammer, and general underwhelming architectures that are maintenance nightmares. Encourage refactoring more. The advice about overuse is patterns is noted, but is a smaller detail, since most programmers don't get to the point of use, let alone overuse.
The one thing I will agree with is whoever they put on the covers of the Head First books, they always seem like they were taken from the wrong advertisement.
Lawrence on February 21, 2009 11:39 AMMy rule of thumb has always been that anyone can program, even a two year old, but only a few are really good programmers. Then there are the elite. Hopefully, by educating the bad programmers, they will do a better job of the legacy they leave behind. Most programmers end up looking at other people's code and say, WTF did he do there? Why did she do it that way? Where did he get that variable? No comments! no documentation!
OO is good in that it is as simple as A PIE Abstraction, Polymorphism, Inheritence, Encapsulation.
That being said, I have seen really, really bad OO Design, which employed none of the above reasons to use OO. Moreover, poor uses of Try/Catch (Sending your exception to oblivion), but that's another discussion.
I have read this book, and it is a pretty good read. It has also been difficult to apply some of the concepts, and I see where people are getting at, and I have used certain patterns in the past, and it has helped me to refine them. I will read the other books that this blog recommends.
I believe that most projects don't allow for anyone to write excellent code, but the natural progression of programming is to:
v1. Write the code in spagetti, maybe using classes here and there, to see if it works.
v2. Fix bugs, and see where patterns can apply.
v3. Continue to fix bugs, and add enhancements, reapplying patterns when useful.
v4. You get to the point where you can't just provide a band-aid solution anymore, and it's time to refactor. Taking all the knowledge you've learned in the past, and build a better OO solution.
v5. Add enhancements, and fix bugs, reapplying patterns can apply.
v6. At this point, you hopefully have a Stable version, that you are just creating enhancements, fixing less bugs. You may have provided an API, and it's easy for your clients to customize the software.
OO has a huge initial cost, and can be geared toward large software development, so my advice is this: strike a balance between using hard to manage spagetti code, and good (not bad) OO design. Time is a huge factor on this scale, and can affect where your project lies on this scale.
The two most useful patterns I think are the State Pattern and Template Method.
CrazyEnigma on March 26, 2009 9:32 AMHi guys,
I heard about Kent's article on Not using design patterns: 23 cheap tricks after reading this article and some more googling. But i couldnt find his exact paper Does some one have it? Please offer me the link to it i am eager to take a look at it
Thanks
So and where should a junior developer begin? The GoF book?
My vote is on The Pragmatic Programmer. That book is a short, very clear, easy to follow overview of most of the fundamentals. Followed up with HFDP it's about the most effective material I've seen for real-world software design.
Unfortunately by the time I got around to reading TPP, it was basically alot of "Hey, I do that!" moments with a few hidden gems. It could have saved me a lot of time a few years ago.
Eric Nicholson on February 6, 2010 9:30 PMWhy OOP is a mess? It's purpose really is reducing messiness by encapsulating code and attributes to meaningful little capsules called classes. Do you prefer global variables over class/object variables?
Of course, if you get some kind of API and it is full of undocumented classes that have unfamiliar names, you are lost and get bogged down. But in general there are reasons for going to OOP from spaghetti.
Don on February 6, 2010 9:30 PMHead First design patterns - O'Reilly
http://www.fileserve.com/file/V5yUZBR
Bossbom Bossbom on July 13, 2010 5:36 AMOh great, complete beginner here, and now seeing this article criticizing this book confuses me even more on what book to start with. I was recommended this book, searched for reviews and saw this... can some1 suggest a real design patterns book for a new engineer?
ShawnRMclean on June 8, 2011 8:54 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |