Quote:Original post by OrangyTang

Quote:Original post by argonaut
However, as my professor thrusts these ideas down my throat, I realized that I've gotten by just fine without many of the patterns presented. Which patterns are most relevant to game design? Which patterns do you like/dislike?

If you're getting on fine without patterns, chances are you're:
1. Writing very small programs.
2. Writing bad code.
3. Using some less formal variant of patterns already without realising it.

4. Using a programming language where the issue that the design pattern is intended to work around simply doesn't exist. [smile]

It's definitely worthwhile learning about and really understanding design patterns. Even if you don't use them all the time and prefer to cook up your own solutions to the problems they solve, they will at very least help you avoid reinventing the wheel.

Design patterns also help you better explain your code to other people and make your code more readable. Instead of going on at length about a solution to a problem you invented, you can simply inform the person you are talking to that you used a mediator pattern. As you might imagine, this can save a lot of time in the long run.

Quote:Original post by Zahlman

Quote:Original post by OrangyTang

Quote:Original post by argonaut
However, as my professor thrusts these ideas down my throat, I realized that I've gotten by just fine without many of the patterns presented. Which patterns are most relevant to game design? Which patterns do you like/dislike?

If you're getting on fine without patterns, chances are you're:
1. Writing very small programs.
2. Writing bad code.
3. Using some less formal variant of patterns already without realising it.

4. Using a programming language where the issue that the design pattern is intended to work around simply doesn't exist. [smile]

"The design pattern"? OrangyTang wasn't talking about a particular pattern. Whilst obviously there are certain patterns which aren't needed in certain languages -- we all know Visitor isn't "needed"* in languages with multiple dynamic dispatch -- not all patterns are a workaround for language failings. For example, Façade isn't a workaround for language failings.

* Of course, in a certain sense it's never "needed" in a language without it. You can always switch on type. The question isn't "can it only be done using Visitor?" but "does using Visitor lead to better code?". As compared to switching on type, it almost always does. Even in languages with multiple dynamic dispatch, it is sometimes desirable to use Visitor.

Additionally, although there are languages where many of the GoF design patterns aren't needed or aren't applicable -- Memento, for example, just plain doesn't make sense in Haskell -- those languages have their own design patterns which in turn don't apply to Java/C++/C#.

Quote:Original post by OrangyTang
IMHO if you start thinking "where can I put pattern X in my code" you'll get overengineered and generally bad results.

QFT

I think to start appreciating patterns, you need to be beyond the "n00b" stage, just because you'll be reading up on some pattern, and you'll think back to cases where that's exactly what would have been elegant (or, where that's exactly what you did, without realizing it was a documented pattern).