Question

I’ve just used it for the first time – consider:

IGameObject
    void Update()

IDrawableGameObject : IGameObject
    void Draw()

I had a level class which used DrawableGameObjects – I switched this to be IDrawableGameObject’s instead to reduce coupling and aid in TDD.

However I of course lose the ability to call Update(..) without casting – to get around this I used inheritance. I’ve never used interface based inheritance before – nor have I really found the need except in this case.

I didn’t really want to cast each time in my update method as it is called up to 60 times a second, on the other hand a foreach(..) could have worked that used IGameObject’s.

Any advice?

Edit

I should add – my fake’s I created afterwards for unit testing then implement IDrawableGameObject – these classes now have many methods instead of just a handful for each interface. I know interfaces must be only a handful of members large, but does inheritance break this rule?

Thanks

Answer 1

I know interfaces must be only a
handful of members large

They need to contain exactly as many members as are necessary to express the concept – no more, no less. There are some quite scary interfaces in the BCL (although maybe you could argue some are oversized).

I’d say this definitely looks like an acceptable use of interface inheritance.

As an aside… if there is implementation logic that only depends on the interface members, consider using extension methods so that the implementing classes don’t need to repeat it… for example:

// just a silly example that only uses members of the target type
public static void DrawComplete(this IDrawableGameObject obj, Canvas canvas) {
   obj.Draw(canvas);
   foreach(var child in obj.Children.OfType<IDrawableGameObject>()) {
       child.DrawComplete(canvas);
   }
}

then all callers get the DrawComplete method without all the implementations having to repeat it.