inheritance vs composition

Page 3 of 3 12 3
06/21/2013 13:32 Mr_PoP#31
you really should be using Interfaces , if you already know that all entities use same common stuff why don't you make them drive from interface!

so eg:
Code:
class IEntity{
virtual public uint32_t getMapId() = 0; // getter
virtual public void setMapId(uint32_t value) = 0; //setter
virtual public uint16_t getX() = 0; // getter
virtual public void setX(uint16_t value) = 0; //setter
virtual public uint16_t getY() = 0; // getter
virtual public void setY(uint16_t value) = 0; //setter
//same for the common stuff
};

class Hero : IEntity{
//then here it will force you to override the methods inside the IEntity.. 
};
why is that useful ? well say you have a Monster/Player/SobNpc those three entities can jump right? so why do you need to make 3 methods of jump for the three when you can have just one?
Code:
void Jump(IEntity entity,uint32_t map, uint16_t toX, uint16_t toY){
    entity.setMapId(map);
    entity.setX(toX);
    entity.setY(toY);
   //send packet to entity...
}
so it's easy now to deal with any type of entities yeah?
06/21/2013 15:44 CptSky#32
Quote:
Originally Posted by Mr_PoP View Post
you really should be using Interfaces , if you already know that all entities use same common stuff why don't you make them drive from interface! [..]
There is no point to make a complete interface. Bunch of getters/setters don't have to be reimplemented. You can put them virtual in case of, but not pure virtual.
06/21/2013 16:57 go for it#33
@Mr_PoP that's what i was going to do in addition to a simple macro automating get/set but instead of using 3 interfaces (inheriting from each other like hero from entity overriding stuff) i was to use just 1 with a perfectly designed access modifiers (aka what's common for all with same methods is public , some protected and some private) then inherit with the suitable access modifier to each
still can't figure out what is the best design i should use :\

@CptSky why not ? (just want to learn :) )
06/21/2013 17:45 Mr_PoP#34
Quote:
Originally Posted by CptSky View Post
There is no point to make a complete interface. Bunch of getters/setters don't have to be reimplemented. You can put them virtual in case of, but not pure virtual.
well IEntity designed to have the COMMON between entities , therefore anyEntity is going to drive from it , has to implement it's methods!
06/21/2013 18:38 CptSky#35
Quote:
Originally Posted by Mr_PoP View Post
well IEntity designed to have the COMMON between entities , therefore anyEntity is going to drive from it , has to implement it's methods!
Yes, but a getter... Like most getter are implemented as:

Code:
int getLook() { return mLook; }
Why would you reimplement this method over and over ? It's the same thing for any entity. Plus, you're adding more overhead for a getter due to the vtable.

Methods like jump/walk, etc. I understand. Getter/setters should be inherited, but not reimplemented.
06/21/2013 18:54 Mr_PoP#36
Quote:
Originally Posted by CptSky View Post
Yes, but a getter... Like most getter are implemented as:

Code:
int getLook() { return mLook; }
Why would you reimplement this method over and over ? It's the same thing for any entity. Plus, you're adding more overhead for a getter due to the vtable.

Methods like jump/walk, etc. I understand. Getter/setters should be inherited, but not reimplemented.
aha in this cases yeah , I was just giving him an example :)
Page 3 of 3 12 3