I find it very funny that you criticize the book, but you link to its Amazon page using your affiliate ID.

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

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

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.

Gosh, 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.

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

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

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

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

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

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

I 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?

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

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.

can anybody tell me two best design patterns?

Jeff, 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

A 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!!!

Yeah, design patterns overuse can bring use in difficult situations, but not using them at all will create a big mess for sure.