inheritance vs composition

npcs , players , guards/bats/pets and monsters/bosses all having coords , hp , size , mesh and more stuff in common
which would fit better inheritance or composition ? and why ?
should i just follow "has a" and "is a" theory ?
edit:
at efficiency they both sounds the same to me as at inheritance it would always go through base class tree until it reach the derived class , at composition it would do the same for custom types to use them at the composite class (the big complex one), not sure if im missing anything behind the scenes but it won't hurt asking

I don't really get your question.

Quote:

Originally Posted by Super Aids I don't really get your question.

in c++ there is Composition/Aggregation that i can use to build up an complex class like monster with small classes like coords , etc.
there is also inheritance
im writing point class as general class that could be used for any bigger class as subclass , im just little bit confused about efficiency for which would fit this situation better for sake of better and more effective design for the source
most of people saying that if the relationship is "is-a" then use inheritance, and if the relationship is "has-a" then use composition

It's quite logical.

Mobs, Players, NPCs, Sobs... are entities. Thus it would be logical for them to inherit either a base entity class or an interface (Something like IEntity.)

Depending on your map/screen system then they may also be map objects which is basically objects spawned on the maps (lol?) and thus inheriting a base class or an interface for that would be logical as well (Something like IMapObject.)

The difference on the two inheritances is that the map object inheritance would contain stuff like screen, map, x, y etc. where IEntity would contain things like name, level, hp, mp etc. Some things may be shared by both inheritances as well, such as uid.

An example on where you wouldn't want to use inheritance, but rather a composition or aggregation would be Inventory for players. A player is not an inventory, but has an inventory, so it would be obviously to have an object instance to some sort of inventory class.

Let's take this to a real world example and let's use a vehicle as the example.

Inheritance = Blue.
Composition = Green.
Aggregation = Red.

A car is a vehicle, but contains a motor and wheels.
A boat is a vehicle, but contains a motor and no wheels.

In that case it would be common to have a base class or interface for vehicle that takes an instance of motor, however only the Car class would have an instance of wheels.

I'm not sure if this is what you asked :s

Quote:

Originally Posted by Super Aids It's quite logical. Mobs, Players, NPCs, Sobs... are entities. Thus it would be logical for them to inherit either a base entity class or an interface (Something like IEntity.) Depending on your map/screen system then they may also be map objects which is basically objects spawned on the maps (lol?) and thus inheriting a base class or an interface for that would be logical as well (Something like IMapObject.) The difference on the two inheritances is that the map object inheritance would contain stuff like screen, map, x, y etc. where IEntity would contain things like name, level, hp, mp etc. Some things may be shared by both inheritances as well, such as uid. An example on where you wouldn't want to use inheritance, but rather a composition or aggregation would be Inventory for players. A player is not an inventory, but has an inventory, so it would be obviously to have an object instance to some sort of inventory class. Let's take this to a real world example and let's use a vehicle as the example. Inheritance = Blue. Composition = Green. Aggregation = Red. A car is a vehicle, but contains a motor and wheels. A boat is a vehicle, but contains a motor and no wheels. In that case it would be common to have a base class or interface for vehicle that takes an instance of motor, however only the Car class would have an instance of wheels. I'm not sure if this is what you asked :s

yup it's kinda what i want and yup i like the inventory example
well there is some situations where you won't want to use inheritance (maybe yeah for inventory example as you won't want to get variables and methods but an object for inventory)
but there is still more examples that could use both , maybe like coords/mob
mob could get all variables for coords and use them directly (through inh.) and could get an object and access them with this object (through comp.)
why would i in this situation prefer someone and not the other , i feel composition are more organized
thanks for helping me out :)

Here's my take on when to use composition vs. inheritance. Composition is normally used when composing one or more classes together via a wrapper class. For example, I have my "Client" class that encapsulates (is composed of) instances of the "Character", "Screen", "Inventory", and other game classes. I can thus call the client's inventory as such: client.Inventory. Inheritance is usually used to inherit a base to built upon it. For example, in my asynchronous socket system, I built upon the .NET Framework's Socket class. I can then control the socket as I would normally without having to call some composed class (such as "AccountServerSocket.Socket", it would be just "AccountServerSocket" to access that socket). I also use it to inherit socket methods and socket variables to my "Client" class. It allows me to focus on the client rather than the base of the client (allowing for easier expansion). Using inheritance, you can make a very expandable server - that's because you can use an abstract (must be inherited to be used) base more than once to have multiple types of a base. It also increases the modularity of your code, which is a huge plus. It all comes down to style and when you feel it should be used. They both have their purposes.

it never ceases to amaze me anytime fang mentions inheritance he makes it seem soooooooooooooooooooooooooooooo much more complicated than it really is...

Quote:

Originally Posted by InfamousNoone it never ceases to amaze me anytime fang mentions inheritance he makes it seem soooooooooooooooooooooooooooooo much more complicated than it really is...

it's way more complicated for me specially when it comes to diamond inheritance and access mod. options
but away from that what do you think about the subject ? which would fit better ?

Inheritance gives you more options in my view, you can create 1 array of IEntities and never need to cast in order to deal with those shared properties, then only cast if/when you actually need to drill into the specifics

Quote:

Originally Posted by Korvacs Inheritance gives you more options in my view, you can create 1 array of IEntities and never need to cast in order to deal with those shared properties, then only cast if/when you actually need to drill into the specifics

i agree that inheritance would help me looping or using arrays without assigning but on the other side i need to take care of everything virtual (plus on a side note it would be kinda too confusing to debug/trace), yup more options and control in price of cleaning everything up (including access specifying for functions and variables so everything looks clean , ctors , initialization , virtual functions , virtual destructors, virtual assignment, overriding virtualization , etc.)
is it worthy ?

Make a judgement, is the cost saving from easier management of objects through out the server worth the cost. I don't know about C++, but it certainly is in C#.

Quote:

Originally Posted by go for it i agree that inheritance would help me looping or using arrays without assigning but on the other side i need to take care of everything virtual (plus on a side note it would be kinda too confusing to debug/trace), yup more options and control in price of cleaning everything up (including access specifying for functions and variables so everything looks clean , ctors , initialization , virtual functions , virtual destructors, virtual assignment, overriding virtualization , etc.) is it worthy ?

Looks like it is complicated in C++ while it isn't at all. If you don't use inheritance for entities, I will say that it's a bad design. If you stop yourself to use inheritance due to the requirement of supporting virtual things, you're not making a good choice at all. After all, virtual destructors imply like one keyword. Overriding virtual is only for pure virtual (by the way, the Entity class should be an interface, or in C++ a pure virtual class). It won't be really harder to debug, at least with a good debugger... C++ is a language where you must take care of everything, one more thing shouldn't be a problem ;)

Inheritance adds overhead due to the vtable, but there is way more benefits to use it for something like entities.

Quote:

Originally Posted by CptSky Looks like it is complicated in C++ while it isn't at all. If you don't use inheritance for entities, I will say that it's a bad design. If you stop yourself to use inheritance due to the requirement of supporting virtual things, you're not making a good choice at all. After all, virtual destructors imply like one keyword. Overriding virtual is only for pure virtual (by the way, the Entity class should be an interface, or in C++ a pure virtual class). It won't be really harder to debug, at least with a good debugger... C++ is a language where you must take care of everything, one more thing shouldn't be a problem ;) Inheritance adds overhead due to the vtable, but there is way more benefits to use it for something like entities.

it's turning to be way more complicated when you want to do something that is really significant with lower knowledge/practice than it requires :)
ill try to code everything more than once and see possibilities and which will be better
still need to pick up more stuff like interface/pure virtual class vs template
thanks for the info and motivation :)

Quote:

Originally Posted by go for it it's turning to be way more complicated when you want to do something that is really significant with lower knowledge/practice than it requires :) ill try to code everything more than once and see possibilities and which will be better still need to pick up more stuff like interface/pure virtual class vs template thanks for the info and motivation :)

Template are for things like container, where the actual type of the object doesn't matter and the code is generic. Nothing related to entities design.

By the way, send me a PM if you need help or want somebody to review your code.

Quote:

Originally Posted by CptSky Template are for things like container, where the actual type of the object doesn't matter and the code is generic. Nothing related to entities design. By the way, send me a PM if you need help or want somebody to review your code.

you are so going to get spam XD lmao just kidding but i definitely appreciate your help , will pm you once i've something that worth your time
thanks alot :)