   Need help organizing my code
  Hello,I wasn't too sure where to put this so I opted for the beginner section.I am currently writing my own 3d game engine (for learning purposes) and I am having a hard time organizing my classes.Currently, my setup is like so (using DXUT):I have 3 main base classes:-Renderer base class-Input base class-Debugging base classEach have derived classes for more specific objects...For example, Renderer has a child camera which implements different cameras (1st person, 3rd person, etc...).Input has children for joystick, keyboard, mouse implementation.Now my question is how can I keep those classes completely separated?  For example, the keyboard derived class will have methods used to move the camera, so it must have multiple inheritance from the Camera and Input class.  This doesn't sit right to me as the Input and Renderer base classes should be isolated from each other.  Is there a way to communicate between derived classes of different base parents without using multiple inheritance?This is hard to explain in words, but I hope someone understands and can point me in the right direction.Perhaps a callback mechanism would be ideal?Thank you.[Edited by - french_hustler on April 19, 2010 5:58:39 PM]
  One class should never directly control another. "Best" practice is to put the input class data into a generic form that the camera can understand (Thrust, Fire[], Eject, yada...), then pass that data to the camera (Or other controlled object), to deal with in its own way.More generally, if you want Class A to be able to affect Class B, you code Class A to generate generic data which is then passed to Class B. Class B then deals with that data in its generic form, with no need to know where it came from.   ;  Multiple inheritance? That's not something you should commonly be using.Inheritance encodes an 'is-a' relationship. It's not true to say that a Keyboard is-a Camera. It's sort of true to say that a Keyboard is-a Input, though I'd rename 'Input' to 'InputDevice.'Another type of relationship is Composition, which is a 'has-a' relationship. When an object of class A has-a object of class B, you encode that by giving A a member variable of type B.What you want, though, is a third kind of relationship - a 'uses' relationship. It's not true that a Keyboard is-a Camera, and it's not really true that the Keyboard has-a Camera, because it's not like the Keyboard owns the Camera, is completely responsible for it, and so on. Encoding a 'uses' relationship involves the object getting a pointer or reference to the object it's using: Keyboard should have a Camera* (or Camera&) as a member variable, most likely.   ;Another option is to use the command pattern for a solution to this. I'm not that much of an expert but I think it is a good candidate for your particular problem.The keyboard (inherited from input) class is the client instantiating a new command object, and the camera (inherited from renderer) class is the receiver receiving the command object.Note that the receiver (the camera class) does not need to know if the command object it receives comes from a keyboard, mouse or AI object. It just receives it and does whatever operation it encapsulates.You can read about the concept in the link above, or buy the book Design Patterns: Elements of Reusable Object-Oriented Software;  I've tried the Command Anti-Pattern. It's a tremendous annoyance and doesn't actually add anything.   ;  Yeah, Command is waaaaay over the top for this. It'd be useful if, say, you were implementing an Undo/Redo system - but this is camera controls, for god's sake.   ;  I was about to say that the command pattern could be overkill but I really dont think it has to be. You just apply the concept in a manner that suits the situation. So, keeping a "history" of input movements might not be worth it but I would say using a messaging system with some kind of message encapsulation would be.   ;  Creating entire Command message objects is really heavyweight, though. It means defining some kind of class to store the message. It means allocating a new message object every time a key is pressed (and allocations are to be avoided!). It means disposing of the message object afterwards.And what's the benefit? So that the camera doesn't need to know who it's getting its orders from. Well, there's another, much more obvious, much simpler, much lighter-weight way to achieve that: The camera just provides public methods for controlling it.There's a reason why many object-oriented languages (e.g. Smalltalk) refer to method calls between object as 'message-passing.' Calling camera->MoveLeft(1.0) effectively is sending a message to the camera, but without any of the overhead of creating Command objects to encapsulate that.   ;  I could agree with that but I don't think giving the keyboard a camera pointer seems like a good idea.   ;  Why not?   