   Class Relationships
  Do Player and Monster classes inherit Physics(is-a) or is it a 'has-a' relationship? The Physics class is defined as collision detection and gravity simulation.I've asked friends but I could not get a definitive answer. Thanks[Edited by - khiosa on June 3, 2010 7:28:35 AM]
  Gravity is not an object but it is a constant when dealing with physics. You are not gravity but you react to gravity. Your "walking" behaviour handles physics and so does your "walking in space" behaviour.   ;  I could not come up with another name at hand so I stuck to gravity. Basically, this 'Gravity' class encompasses collision detection and gravity simulation. Sorry about the confusion.I guess 'Physics' would be more appropriate.   ;  Usually it's done via an is-a interface, as in: CJimmy inherited from IPhysical (or whatever you want to call it), as in it is an object that can interact with physics.Of course, as always, there isn't really a "right" way of doing it: If the has-a works better as a solution in the situation, you could use that and nobody would "look down on you" because...you know, it works ;P   ;  These days, component-based designs are generally favored over deep inheritance trees. Keep in mind that inheritance is a very 'close' relationship. Composition (has-a) is often more flexible. Different responsibilities are easier to split up with components, whereas with inheritance, you end up with a single object that fulfills multiple roles at once.   ;  I generally only use inheritance (is a) if I have to (because objects become too inflexible with excessive inheritance), so I'd go with composition (has a).   ;  Suppose I chose the 'has-a' approach and decided to go with the classes below :Suppose, (C++)class Physical{public int getX(){ return _x; }private int _x;};class Player{public int getX(){ _physical.getX(); }private Physical _physical.};Would I have to reroute every public function in Physical to have it in the Player class as I did there? I prefer a component-based design. I think this is a C++ specific question.   ;  Make _physical public.You do the whole error-checking in the Physical class, so I think theres no reason to make a get/set function in the Player class.   ;Quote:Original post by highendmanMake _physical public.You do the whole error-checking in the Physical class, so I think theres no reason to make a get/set function in the Player class.I would still have to refer to it through Player_object_name._physical.getX() which is ridiculously long; it also violates encapsulation I believe.There has to be a way around this.;  then shorten the names: player.physic.x(), or player.physic.x(10); isn't that bad.And by the way:The more members your Player class gets, the more ambiguous method names you get: Probably one or two members of your Player class have an own member called x. Then you have a problem with long names, too: player.getX_blah(), player.getX_blahblah(), etc.   