Head First Design Patterns

blog
21

yuch - 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…)

22

In 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.

23

The 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!).

24

So 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.

25

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.

26

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

1 Like
29

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?

1 Like
30

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.

31

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.

32

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

33

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.

34

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.

36

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?

37

@ 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…

38

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.

39

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.

40

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?

41

@codinghorror This is perfect! Except for one thing. :frowning:
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. :weary:

1 Like
42

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.

45

Unfortunately I bought Head first Design Patterns book , believe me it is really annoying and wastage of time.