In terms of game engine modeling, please give your pros and cons for two types of interfacing:

class MySceneObject_Model1 : public IRenderable, public IScriptable, public IAnimatable { ... }

class MySceneObject_Model2
   IRenderable* m_ptrRenderable;
   IScriptable* m_ptrScriptable;
   IAnimatable* m_ptrAnimatable;


   IRenderable* GetRenderable();
   IScriptalbe* GetScriptalbe();
   IAnimatable* GetAnimatable();

What if MyObjects have different variations of supported interfaces? For example one of them can be only Scriptable. Some of interfaces could appear in future. Some of them could be very similar to each other: IAnimatableByMorphing, IAnimatableByBones, etc. Some of them can be very close to each other: IRenderable depends on new object's state after IAnimatable's work. I know it is very basic and very wide question, but tell about your experience!

  • 6
    \$\begingroup\$ Have you considered component-based design? I think it should solve most of your problems. \$\endgroup\$
    – Gerstmann
    Commented Jan 16, 2012 at 13:14
  • \$\begingroup\$ ExplodingRat, thank you! could you give some link about component-based design? \$\endgroup\$
    – Edward83
    Commented Jan 16, 2012 at 14:55
  • \$\begingroup\$ It's very popular topic these days, even this site has tons of information about it. \$\endgroup\$
    – Gerstmann
    Commented Jan 16, 2012 at 15:21
  • \$\begingroup\$ Component-based design is the currently-trendy implementation of composition. Has lots of advantages, and some disadvantages compared against other types of composition. \$\endgroup\$ Commented Jan 16, 2012 at 21:52

2 Answers 2


It is generally preferable to prefer composition to inheritance. There are many available resources on the subject if you ask Google about it. According to that principle, your second example is better. If you take the first approach you will have to implement IAnimatable (or whatever) in every concrete game object class, and you may not be able to easily re-use that code unless you take an approach that is far more like the second option anyhow. This will, in turn, imply you have many different game-object level classes that exist only to mix-and-match different interface implementations. You could achieve this more easily, more cleanly, and with less code using the second approach and simply configuring an object with the appropriate interface implementation objects.

Your second example is actually a very primitive component-based architecture, one where the available component set is rigid. What Edward83 was suggesting in the comments is probably the (currently very trendy) evolution of that architecture where objects are composed of a dynamic list of components.

In the second example, if an object does not supporting animation or scripting, the respective components would be null or you would install a dummy component that implements the interface but does so with no-op methods.

As a note, you probably should not have "IAnimatableByMorphing" or "IAnimatableByBones" interfaces (as implies by the 'I' prefix), rather those should be concrete classes that implement IAnimatable.


as others have said, prefer composition over inheritance. you may find Refactoring Game Entities with Components to be of interest.


You must log in to answer this question.

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