   More Inheritence
  This is my game structureActor->Object->Character -> PC  -> NPC -> Shopkeeper (Example)    -> Soldier (Example)<-------- Combative    -> Guard (Example)  <-- I have a set of variables and methods that allow the Characters to participate in the combat system of my game (shown as combative).How do I make it so the Soldier and the Guard can inherit these methods while the shopkeeper does not? I think multiple inheritance would be the solution, but I can't do that in java.Thoughts?   
  You would have to fracture your inheritance tree, and depending on how much else you need to cram in there it may not work out well. Better to simply put the combat methods in "Character" or something and have the shopkeeper leaf class implement them as no-ops. This is exactly what you're saying after all -- a shopkeeper is a character who doesn't engage in combat, so when told to Fight() he does nothing.This approach you've taken to inheritance isn't ideal -- you should in general favor composition over inheritance. Also, while you haven't given much detail about each level of that inheritance tree, if the objects in question do what they sound like they do there is really no need for them to be different types. They can achieve the same results simply with different data.What do the "combat related methods" look like? What are they called, what impact do they have?   ;  If C++ inheritance is your choice, you may use the "Builder" design pattern for this. The idea is to first declare all methods for the shopkeeper, Soldier and the Guard in an abstract class (interface) regardless of which is for which:class BaseAction {public:virtual void SoldierGuard_1() = 0;   virtual void SoldierGuard_2() = 0;virtual void shopkeeperOnly() = 0;   virturl ~BaseAction(){}};class shopkeeper :: public BaseAction{};class Soldier :: public BaseAction{};class Guard :: public BaseAction{}; Then selectively implementing them using the "Builder" design pattern as follows:void shopkeeper :: shopkeeperOnly(){implement it for shopkeeper};void shopkeeper :: SoldierGuard_1(){};// NO Imp !void shopkeeper :: SoldierGuard_2(){};// NO Imp !void Soldier :: shopkeeperOnly(){};// NO Imp !void Soldier :: SoldierGuard_1(){implement it for Soldier};void Soldier :: SoldierGuard_2(){implement itfor Soldier};void Guard :: shopkeeperOnly(){};// NO Imp !void Guard :: SoldierGuard_1(){implement it for Guard};void Guard :: SoldierGuard_2(){implement it for Guard};;  You can have a Combatable interface. And the things that fight... implement the interface, and the shopkeeper would implement maybe a shopable interface.Basically, lookup interfaces in java, and how they are used.So... back to your code... Actor->Object->Character -> PC  -> NPC -> Shopkeeper (Example) Implements Shopable    -> Soldier (Example)  Implements Combatable    -> Guard (Example)    Implements Combatableyour Combatable interface would have something like Attack() which a soldier and a guard would override and implement on their own.the shopable interface would have a function like OnSelection(shopkeeper.inventory) that would open up a UI window for the given inventory.   ;Quote:Original post by AverageJoeSSUYou can have a Combatable interface. And the things that fight... implement the interface, and the shopkeeper would implement maybe a shopable interface.Basically, lookup interfaces in java, and how they are used.So... back to your code... Actor->Object->Character -> PC  -> NPC -> Shopkeeper (Example) Implements Shopable    -> Soldier (Example)  Implements Combatable    -> Guard (Example)    Implements Combatableyour Combatable interface would have something like Attack() which a soldier and a guard would override and implement on their own.the shopable interface would have a function like OnSelection(shopkeeper.inventory) that would open up a UI window for the given inventory.Yes but I would have to implement this interface for both the guard and the soldier, basically copying and pasting code.;Quote:Original post by jpetrieYou would have to fracture your inheritance tree, and depending on how much else you need to cram in there it may not work out well. Better to simply put the combat methods in "Character" or something and have the shopkeeper leaf class implement them as no-ops. This is exactly what you're saying after all -- a shopkeeper is a character who doesn't engage in combat, so when told to Fight() he does nothing.This approach you've taken to inheritance isn't ideal -- you should in general favor composition over inheritance. Also, while you haven't given much detail about each level of that inheritance tree, if the objects in question do what they sound like they do there is really no need for them to be different types. They can achieve the same results simply with different data.What do the "combat related methods" look like? What are they called, what impact do they have?The combat related methods are things like attack(character), levelUp(), various variables such as attack speed, hit ratio, and damage. This is all in Java btw.How would composition vaguely look? I've read about it but it inheritance seems to be more applicable at the moment.   ;Quote:Original post by overeasyYes but I would have to implement this interface for both the guard and the soldier, basically copying and pasting code.Not true at all.... the whole point of an interface is to group similar functionality of objects into a central thing.If you are writing similar functions in each class, then you simply write it once in the interface, and dont override it in the implementing classes. I say you write attack twice because maybe a soldier and a guard attack differently, even then you could make it so the one attack function takes input like fighter type, and processes the attack in that fashion.   ;Quote:Original post by AverageJoeSSUIf you are writing similar functions in each class, then you simply write it once in the interface, and dont override it in the implementing classes.Since when did Java allow putting implementation in an interface?;Quote:Original post by SiCraneQuote:Original post by AverageJoeSSUIf you are writing similar functions in each class, then you simply write it once in the interface, and dont override it in the implementing classes.Since when did Java allow putting implementation in an interface?It doesn't...   ;Quote:Original post by overeasyYes but I would have to implement this interface for both the guard and the soldier, basically copying and pasting code.So... why make two classes for them? It's very likely that you can get away with just one class - guards and soldiers would then be instances of this class, just with different data.Just because a guard, a soldier and a shopkeeper are different, gameplay-wise, doesn't mean that your class hierarchy should reflect that. A while ago I worked on a turn-based strategy. We designed a unit type class that contained type information (range, ammo capacity, speed, etc) and a single unit class, that had a reference to a unit-type instance. We had infantry, vehicles, airplanes... all with two classes and a bunch of different data. I'm not saying that that's the best approach for you, but I'm telling you to give you a different point of view on this issue.   