Alistair Doulin wrote this in 2011 for a Game Developer featured blog, reposted from his own site. The premise: Robert C. Martin’s five class-design principles are standard vocabulary in business software and “generally unknown amongst game developers.” What makes it worth reading years later is the framing — every principle is paired with a “When have you got it?” smell test written in game code rather than design theory.

The five principles, in his game-specific terms:

  • Single Responsibility — one reason for a class to change. Multiple responsibilities mean coupling, and the bug reports read like why did changing from rendering API break jumping?
  • Open/Closed — open for extension, closed for modification, mostly via data-driven design: configuration gets passed into the class from the calling code instead of being hardcoded.
  • Liskov Substitution — derived classes usable without the caller knowing their type. The tell is RTTI: a GameEntity branching on “am I a Tank” has already broken it.
  • Interface Segregation — clients should not depend on interfaces they do not use. Break fat interfaces into one small group per client.
  • Dependency Inversion — high-level modules depend on abstractions, not low-level modules. He flags this as the one game devs find least familiar, because it inverts the habit: the client does not construct what it needs, it is handed an interface by whoever owns it — usually the engine.

The smell tests are the useful part. The 500-line GameObject everyone throws code into. The file you dread checking in because everyone is editing it. A base class interrogating its own type at runtime. Blank-line groupings inside an interface definition — whitespace as a signal the interface wants splitting. Concrete-class references between two systems that should be talking through interfaces.

His sharpest point is about Liskov, and it is a game-code argument rather than a theoretical one: a class cannot be validated in isolation. A new Tank class is not proven correct until it runs in context with its parent, siblings, and the rest of the systems — which is why the base-class contract, not the class itself, is where the design actually lives.

Read it with the date in mind. This is 2011 C++ with deep inheritance hierarchies, and the industry has since moved toward composition and data-oriented design, which attacks entity coupling from a different direction. As a class-level review checklist it still holds up; as an answer to entity architecture it has largely been superseded.