inheritance vs composition

[Mr_PoP]

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:

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?

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?

[CptSky]

Originally Posted by Mr_PoP

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.

[go for it]

@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 )

[Mr_PoP]

Originally Posted by CptSky

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!

[CptSky]

Originally Posted by Mr_PoP

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:

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.

[Mr_PoP]

Originally Posted by CptSky

Yes, but a getter... Like most getter are implemented as:

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