The question is pretty self explaining: doesn't multiple inheritance solve all the problems that entity systems also solve?

I just remembered a term called "multiple inheritance", and that seems to solve a lot of bloating problems that classical inheritance imposed.

  • 1
    \$\begingroup\$ Multiple inheritance is similar to entity systems, but it's not the same. For example, multiple inheritance entities cannot have components added and removed at run-time. Not all languages support multiple inheritance either. You could also consider composition to be in the same category vs entity/components. \$\endgroup\$
    – House
    Jul 26, 2012 at 18:17
  • 2
    \$\begingroup\$ If your classes are already so neat that you can seamlessly inherit them together in any way you like, they might as well be components already. Components also allow composition/aggregation at runtime \$\endgroup\$
    – user13213
    Jul 26, 2012 at 18:19
  • \$\begingroup\$ Well, its more complex and less error prone, so why prefer it? \$\endgroup\$
    – API-Beast
    Jul 26, 2012 at 22:43
  • 2
    \$\begingroup\$ MI doesn't really address "bloat" issues either, as inheriting an excess of interface from a parent class or classes is more a symptom of poorly using an inheritance mechanism rather than of single versus multiple inheritance. The same "bloat" can be achieved in a composition-oriented approach to a problem, as well. \$\endgroup\$
    – user1430
    Jul 27, 2012 at 1:16
  • \$\begingroup\$ @MrBeast do you mean more complex/more error prone, less complex/error prone, or "why not prefer it?" \$\endgroup\$
    – 3Dave
    Aug 17, 2012 at 23:04

2 Answers 2


No, multiple inheritance does not solve all the same problems that entity systems do: entity systems and multiple inheritance are two very different things. You can build an entity system with or without multiple inheritance and similarly you can utilize multiple inheritance without building an entity system.

Traditionally, component-focused entity systems are developed because of a desire to move away from heavy inheritance in any form, aiming instead for composition. There is sufficient literature and discussion elsewhere on this adage, for example on programmers SE or SO itself, and it the larger question of why to prefer composition is sort of off-topic for game development. In short, however, it's an approach that tends to lend itself to improved mutability and maintainability.


Josh's answer is awesome, but I'd like to add:

One of the coolest features of Entity/Component is the data-driven way in which every "thing" in your game is created and managed. From what I've seen, once you have a nice library of component types and systems created, you can build just about anything with minimal code modifications. (Note: minimal != 0)

By defining your game in terms of behavior, and giving yourself the ability to modify those behaviors on the fly - at runtime, during initialization by loading them from a script or database, etc. - you open up an entire world of new possibilities. Want to see why your shadows don't land where you'd expect? Add a camera/POV component to your light.

Entity/component lets you build anything you want, as long as you've created the blocks.

Also, multiple inheritance causes the same problem as single inheritance. When you add an attribute or behavior in the hierarchy, it propagates. As long as you're making deep hierarchies, you'll run into situations where you're carrying unnecessary weight, duplicating code, or resolving conflicts. Most of that can be avoided when you imagine your game as data.

I've just started playing with this in the past few weeks, but I'm impressed at how simple things have become. It's not a silver bullet - I've run across a few cases where attaching a lambda to a component was the cleanest and most expedient way to solve a problem - but it's a pretty great pattern, if you can call it that.

On a slightly related note: one of the big, boring maintenance generators in data-centric applications (websites, etc.) is mapping hierarchical objects into relational databases. We've got lots of nifty solutions around, but they're ultimately all hacks designed to flatten hierarchies. Instead of building your model so that it serves the purpose of the application, you wind up compromising between an effective hierarchy and a logical relational representation. I've been toying with the idea of rebuilding a pretty large hierarchy in one of my apps as an entity/component system - ditch the hierarchy and make the database the Gold Standard for the rest of the implementation - and it's promising.

When you integrate capabilities like dynamic code generation/code caching that can address performance issues, you wind up with a fast, flexible, logical architecture that might just realize the reusable code goal of OOP in a much, much better way.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .