I 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
Jeff 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?
You 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.
My 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.
Hi 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.
Why 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.
Oh 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?
@ ShawnR and other wondering the criticism of the book…
Every programmer has a right to advice…the author of the article did not say that the book “Head First Design Pattern” is bad and will make you a bad programmer. He has reservations on some of the advice given in that book…
The experts like Sophistication…but one should belive in learning rather than trying to be sophisticated…what I mean is if you are not a guy who would be able to digest “GOF design pattern book” and would not read head first just because sophisticated programmers don’t recommend it highly or criticise some part of it…then it is foolish…these Head First Guys are doing an amazing job. They give you a great starting point…specially Head First Design pattern is outstanding book as a starting point…
I appreciated the sarcasm here. Perhaps if we approached design patterns as choices that entail risk, it would be better. The GoF address this in the Consequences section of each pattern. YAGNI and KISS are always low-risk choices.
On the other hand, I like Head First because it shows the messes that result if a pattern is not applied (e.g. Decorator is glorious). GoF takes it a bit for granted that some “suffering” has occurred already in the readers experience.
As for junior coders applying patterns in production code, I was never allowed to do crazy stuff at my first real coding job (Apple) in 1990, because senior peers reviewed the code and mentored me into being reasonable. Programmers need to learn to take risks (applying patterns) and the best way to learn is by making mistakes.
Fairly new to programming and have only glanced at design patterns myself, but from the little I have read I was under the impression that design patterns occur “naturally” in code, a common way to solve certain problems. If so, it would be difficult if not impossible to write good code without using patterns.
Having said that, I tend to agree with those who say it’s better to focus on learning good programming practices, the patterns will come naturally and by writing good code it’s easier to refactor it into patterns as some suggest.
Most patterns worth naming are more complicated than the “Flip a Coin” pattern that is the pattern of going in one of two different directions by choosing either the if or else clause. Committing to a pattern too early just doesn’t feel like agile think IMHO.
Design patterns are also a fancy term for “best practices” that some folks have tried to codify. I get it, but I have an almost impossible time understanding the uml that goes with them that supposedly lays it all out. They are like hieroglyphics to me. But I do understand the textual descriptions and the concepts. My problem with them is that they are tied almost always to uml diagrams and my brain just doesn’t grock diagrams well. A learning thing. And as a best practices guide they make these rigid diagrams so that people will often try to fit the dodecagram (almost round) into a round hole. And it might as well have been square.
As for beefing on them about where they put the disclaimer, I think you were a little over the top. Has ten years mellowed you on it?
@codinghorror This is perfect! Except for one thing. 
The last part about the head first girl is the only thing keeping this article from being sent to my team.
Your blog is respected at my office but we’re hyper-sensitive to anything sexual, as a lot of the team is female and we like to keep everything gender neutral.
Do you think it’d be possible for a link to this article that lacks the paragraph about the head first girl? Because this article is exactly what my team needs to read. They are addicted to overcomplicating design with unnecessary patterns. 
Personally I think this is a great book, I found the Head First style quite annoying at first but considered their reasoning and found it works well.
I found this a really good book to learn how to put patterns into practice.
Yes, applying patterns unnecessarily is foolish and dangerous, maybe their caveat should have been right at the beginning of the book, but if you do a lot of reading around software dev you should be aware of KISS and YAGNI and hopefully you are of the mindset that these things are just tools for the box, not something to be applied everywhere you possibly can.
Anyway, I think your point is totally valid, however I think this book is a good resource.
Unfortunately I bought Head first Design Patterns book , believe me it is really annoying and wastage of time.
Ah, we just wanted to make learning Design Patterns fun. It’s up to you if you choose to use them or not. I do think that having some knowledge about patterns and principles can help you. And of course we put in the disclaimers about over-reliance on patterns, we put it at the end so as not to discourage people before they even start!
Regarding the cover: we wanted to make design patterns accessible to women and show that women can code too. This is not a “sexual” cover, it’s a strong, fun woman. At least that’s the way I see it (as a woman). But obviously everyone will have their own opinion about that.
Sorry you didn’t like it! Head First is definitely not for everyone.
Cheers!
Elisabeth
I love this book. It’s one of the best technical books I’ve read, it’s fun an far from dry. (maybe a little repetitive)
If you read a book and start using all of it without thinking you are stupid and it’s not the books fault IMO.
I don’t see the point of all the rant and negative comments here. Before denigrating the work of somebody you should read it attentively at least once and deduce that this different approach is beneficial because you don’t shove information into your head as you would normally do with other books. Their approach works really well by using redundant explanations and images… well, at least for me. If you are a senior programmer that already knows all paradigms and design patterns and just needs a good reference, then don’t read this book, but for us as junior programmers this comes in handy and, therefore, GoF can be considered a complement to it.
Was it really necessary to comment about the model in the cover? Oh, wow, two different clients bought the same stock picture… and one of them used the picture to illustrate some uniformed-shitty-text making girls feel bad about their anatomy.
Also, is being a stripper something bad or laughable? Do those comments serve for any purpose other than make women feel like we are less deserving human beings?
Please, please, please remove the tasteless commentary about the cover. I really doubt you want to have to explain this post to your daughters when one of them gets their first yeast infection.