How to avoid "clutch" in OOP?

Question

Well, I'm not sure the connection describes my problem. The problem is that I create my own ogre-based game engine. I also use the PhysX physical library, but since I need to create an abstraction layer between my main engine code and PhysX - so just in case we could use a different physical engine - I decided to create a Quantum shell.

• So, ogre has an Entity class that will manage the entity on screen

• PhysX also has a PxActor class that contains information about the position of an actor in PhysX.

• The quantum wrapper will have a QEntity class that will act as a layer between the engine and PhysX

• Finally, the engine will have an Entity class that will have at least two members, an ogre object object, and a quantum entity. On each update() it will ask QEntity what to do and update the position of the ogre object.

Identify the problem? 4 classes for one object? And remember that we need to get access to all four objects at least 60 times / s! So what about data sharing? Not very optimized. In addition, there may be more classes, one for AI, one for the script engine ...

Answer 1

Using objects of several classes to represent the same thing in several contexts is not bad in itself. In fact, it would probably be worse if you used the same object in all these contexts - for example, through some creative use of multiple inheritance.

Your QEntity class QEntity already disabled for you - while you program its interface and do not allow PhysX specific classes to stick out of the QEntity ^* interface, you are good.

It looks like your project introduces coupling in the "bridge" classes, which is exactly where it belongs. As long as you keep it there, your design will not have communication problems.

As for the 60 FPS, don't worry too much about this during the design phase. As long as there are no long chains of responsibility based on virtual functions, your compiler should be able to do a good job optimizing it for you.

^* for example, QEntity should not accept parameters or return objects specific to PhysX , except for the constructor that creates the "wrapper".