I consider design patterns to be one half of learning OOP where language (C++, C#, Java) is the other half. Typically, programmers learn a language like C++ and are left wondering what to do next. This is where patterns come in are (usually) very useful. However, like anything pertaining to programming, they need to be practiced extensively.

We've argued pretty frequently here in the past about which patterns are evil and which are good so I don't want to get into that discussion. You can probably google the gamedev forums and get plenty of pros and cons that way.

The blog is crap.

The problem isn't that he used design patterns (after all, his friends got very good scores), but that he didn't sufficiently gather requirements (read the question). If you don't sufficiently gather requirements, the chances of satisfying them drops dramatically even if you're great at writing code and have the best tools available.

A bad engineer is a bad engineer even if better tools allow them to suck more efficiently.

Quote:we were computer scientists for chrissake, we don’t care about statistics!

This is wrong on so many levels I don't even know where to begin. Do you think the infamous CLR book has a whole part &#111;n statistics as filler?..<br><br>While Ericson's blog has some very useful graphics-related talk usually, this post is a joke. The guy tried to pass a statistics exam by memorizing the problem types, not understanding the underlying concepts, for god's sake, and he deserves an F for that. I remember my quantum mechanics professor giving MCQs that're almost the same as lat year's exam except for minor ord changes to massive effect. Everyone who's memorizing failed, period. You want to pass statistics you go and actually understand what it is..

Quote:Original post by force_of_will
I would like to know, what you guys think about Design patterns are they evil or not?

Of course they're not evil...
Saying that patterns is evil is like saying that it's evil to build a house that has named rooms like "bedroom", a "bathroom" and "kitchen"!
This is what comes to mind when I think of someone that thinks that the patterns are the problem (and not the person misusing the patterns):
"Naming rooms like that makes you think in the box! Why give names to these supposed 'patterns' when they don't need a name at all! Why call it by the pattern-name of 'bathroom' when we could just call it 'the room with the toilet'!? Stop limiting yourself man! What if I want to put the toilet and the oven in the same room?? Your patterns won't let me man! YOUR PATTERNS WONT LET ME!!!"

Quote:From the blog:
If you didn’t guess it already, The Plank is a design pattern.

^He doesn't say *why* this analogy is true... Why is memorizing the particular metaphor used in a question in a statistics exam comparable to using a design pattern?
The only correlation that I'm seeing is that if you learn computer science the same way that this guy tried to learn statistics, then you will probably use design patterns in the wrong way, just like he used his statistics "knowledge" the wrong way...

Well, the analogy he draws was certainly poor...

I think the point of his rant was that design patterns have a way of permeating the thinking process which can, when misused, become "a solution looking for a problem". This misapplication is the problem, of course, not the patterns themselves.

The problem with this line of thinking is that he seems to liken the process to multiple-choice programming: Any problem statement must match something more or less exactly within a finite set. Obviously this is incorrect, and many actual tests include the ever popular Ds: "None of the Above" and "All of the above".

Design patterns should be viewed as a chest of tools (or parts, rather) -- When one of those tools/parts fits the problem area, you apply it. When it doesn't, you find another solution, which might be bespoke, some combination of other parts, or some mixture thereof.


I do agree with Chris that it probably is dangerous to introduce a new programmer to design patterns too early. Part of the appreciation you build for design patterns is the experience of not knowing about them for awhile and seeing how much work bespoke implementations can be. With luck, an insightful programmer might even start to identify and codify their own patterns, and later come to realize that "their" patterns are really subsets of "the" patterns.

That said, you simply can't blame the tool for it's misuse.