When to use design patterns

You know you’re doing something interesting when the answer to the question of why or when is both maddeningly simple and complex. The answer you’ll hear the most about design patterns is that you should only use them when they’re needed. Helpful, right?

The easiest way to know if you should use a design pattern is if you identify a concrete problem area in your code. Symptoms of a problem include code smells like tightly coupled classes, monolithic subclass hierarchies, and dependencies on specific operations, object representations, and hardware. Hardware and software dependencies are particularly acute in game development when you need to port your code to different devices or systems.

All those symptoms are related to the idea of designing for change, and how easy or hard it is to make changes to your code. This is a topic we’ll explore with each pattern individually, but here are a few high-level red flags to look out for:

• Is a class hard to add to or maintain?
• How much knowledge does the programmer making a change need to have of the entire system they are working on?
• Is it difficult to create slightly different objects from existing classes?
• Does a change in one area crash a secondary or even unrelated part of the codebase?
• Can your code satisfy an operational request in only one way?
• If you’re working with algorithms, does changing the implementation break the object using the algorithm?

If any of these questions ring a bell, then your code could use some design pattern love. But design patterns aren’t all fun and games (pun intended); there are pitfalls with any tool – software or physical – that we have to address before diving in.