Elysian Shadows

I've always wondered, how many interfaces is *too many* interfaces... Is it good to have a lot of interfaces or just a few, or just to have as minimum as possible?

Let's say...

If I had lets say a Transformable Interface that can transform something (e.g. rotate, position, scale), should it be an interface of an interface? In other words, should it inherit it's capabilities from let's say a Rotateable, Positionable, and Scaler Interface, or would it be easier to just jam it all in one interface...?

I know this seems like a stupid question but it's just buggy my mind like crazy at the moment.

Jeeeesus. The only point of an interface is that you can refer to multiple different object polymorphically by their interfaces.

How many other "rotatables" are you going to have that you are going to be referring to by a "Rotatable" base class? The chances are that 90% of the interfaces you make are pointless with a mentality like that...

I'd say that would be a poor candidate for inheritance. The idea is that you wan't to inherit from something that is similar to it's parent in terms of what its inherent nature *IS* not the attributes that it *HAS*. I think that's really a key point there and you have to ask yourself continually: "Is the child a type of the parent?". Is a truck a type of vehicle? Sure. Is an engine a type of truck? No.

Since you're dealing with objects that can rotate and so forth, you would say that they have "transformable attributes". So they CAN BE transformed. However, is the object a TYPE of transform? No, it's not although it has that attribute. So it would be a poor candidate for the inheritance model.

You will also find that with the amount of times that you could conceivably be rotating, scaling, translating an object, you will very rapidly approach being bound up by all of the late binds.

@qpHalcy0n:
It is indeed a property, but I'm not sure if I like the idea to constantly have to refer to the stuff through a middle-hand handle like boat.transform().setRotation(23). I have made a game with boat.position().set(8,24) in the past, though, and that's a little bit better. That kind of stuff works, I guess. However, I still think it makes sense to have a Transformable base class if you're going to have a lot of transformable objects. They inherit properties. That happens with all regular inheritance too. Nothing wrong with that.

I'm going to have to agree with qp...

The only reason you've given for liking inheritance is because you don't like the extra level of composition. With that same philosophy, you could argue against ANY compositions of objects... Something with a collider becomes a collidable. Something with a trigger becomes a triggerable. Something with a texture becomes a texturable? So where do you draw the line? When do you EVER favor composition with such a philosophy?

Why do you favor inheritance anyway? Not because you need to refer to them as their base polymorphically (which would be a legitimate reason)--no, just because you favor the syntax of inheritance over composition. That is abuse.

Look at the direction of today's game engines. There's a reason that they're all moving away from a multiple-inheritance paradigm and towards an "entity/component" model. The misuse of inheritance for just properties like that isn't even legal in modern JIT languages with single inheritance. You could only inherit one parent's properties. Using inheritance to gain "properties" like this prevents you from ever adding or removing these properties at run-time. To create new combinations and permutations of these properties, you are forced to subclass the shit out of the parent classes and recompile... whereas a composite object or entity/component paradigm allows you to dynamically add and remove properties and behaviors to "create new types" at runtime...

qpHalcy0n wrote:You will also find that with the amount of times that you could conceivably be rotating, scaling, translating an object, you will very rapidly approach being bound up by all of the late binds.

You guys especially need to be wary of this when you're abusing the shit out of inheritance with virtual methods--vtables ain't free.

Excellent points by GyroVorbis.

The late binds will kill you if you're going to be doing these things thousands of times per frame. In one of the earliest incarnations of my engine, we had several renderers which were inherited from several foundation interfaces. After reworking the entire topology to remove the late binds, from that alone we saw a jump in performance somewhere on the order of 200%. Now bear in mind, there were thousands and thousands of render calls issued per frame. When you can reduce the amount of times you invoke virtual methods then I think you can arrive at a happy grey area. When you have no choice in that a critical component issues thousands and thousands of calls per frame, then you might want to reconsider the inheritance model. This is especially true if they're interleaved between draw calls, such as transformations. These functions should execute as fast as absolutely possible.

Hell, in the project I've got going now we do rigid body transforms on over 20,000 objects on the CPU. Even without late binds we're bound up in those functions. Dealing w/ the vtable overhead would just add to the problem.

GyroVorbis wrote:I'm going to have to agree with qp...

The only reason you've given for liking inheritance is because you don't like the extra level of composition. With that same philosophy, you could argue against ANY compositions of objects... Something with a collider becomes a collidable. Something with a trigger becomes a triggerable. Something with a texture becomes a texturable? So where do you draw the line? When do you EVER favor composition with such a philosophy?

Why do you favor inheritance anyway? Not because you need to refer to them as their base polymorphically (which would be a legitimate reason)--no, just because you favor the syntax of inheritance over composition. That is abuse.

Look at the direction of today's game engines. There's a reason that they're all moving away from a multiple-inheritance paradigm and towards an "entity/component" model. The misuse of inheritance for just properties like that isn't even legal in modern JIT languages with single inheritance. You could only inherit one parent's properties. Using inheritance to gain "properties" like this prevents you from ever adding or removing these properties at run-time. To create new combinations and permutations of these properties, you are forced to subclass the shit out of the parent classes and recompile... whereas a composite object or entity/component paradigm allows you to dynamically add and remove properties and behaviors to "create new types" at runtime...

qpHalcy0n wrote:You will also find that with the amount of times that you could conceivably be rotating, scaling, translating an object, you will very rapidly approach being bound up by all of the late binds.

You guys especially need to be wary of this when you're abusing the shit out of inheritance with virtual methods--vtables ain't free.

Wise words. One definitely shouldn't overuse inheritance, but I still think it does make sense to have an Entity class with at least a position and perhaps even collision. Then you can add components to that basic entity.