Another design-related C++ question
- by Kotti
Hi!
I am trying to find some optimal solutions in C++ coding patterns, and this is one of my game engine - related questions.
Take a look at the game object declaration (I removed almost everything, that has no connection with the question).
// Abstract representation of a game object
class Object :
public Entity,
IRenderable, ISerializable {
// Object parameters
// Other not really important stuff
public:
// @note Rendering template will never change while
// the object 'lives'
Object(RenderTemplate& render_template, /* params */) : /*...*/ { }
private:
// Object rendering template
RenderTemplate render_template;
public:
/**
* Default object render method
* Draws rendering template data at (X, Y) with (Width, Height) dimensions
*
* @note If no appropriate rendering method overload is specified
* for any derived class, this method is called
*
* @param Backend & b
* @return void
* @see
*/
virtual void Render(Backend& backend) const {
// Render sprite from object's
// rendering template structure
backend.RenderFromTemplate(
render_template,
x, y, width, height
);
}
};
Here is also the IRenderable interface declaration:
// Objects that can be rendered
interface IRenderable {
/**
* Abstract method to render current object
*
* @param Backend & b
* @return void
* @see
*/
virtual void Render(Backend& b) const = 0;
}
and a sample of a real object that is derived from Object (with severe simplifications :)
// Ball object
class Ball : public Object {
// Ball params
public:
virtual void Render(Backend& b) const {
b.RenderEllipse(/*params*/);
}
};
What I wanted to get is the ability to have some sort of standard function, that would draw sprite for an object (this is Object::Render) if there is no appropriate overload.
So, one can have objects without Render(...) method, and if you try to render them, this default sprite-rendering stuff is invoked. And, one can have specialized objects, that define their own way of being rendered.
I think, this way of doing things is quite good, but what I can't figure out -
is there any way to split the objects' "normal" methods (like Resize(...) or Rotate(...)) implementation from their rendering implementation?
Because if everything is done the way described earlier, a common .cpp file, that implements any type of object would generally mix the Resize(...), etc methods implementation and this virtual Render(...) method and this seems to be a mess. I actually want to have rendering procedures for the objects in one place and their "logic implementation" - in another.
Is there a way this can be done (maybe alternative pattern or trick or hint) or this is where all this polymorphic and virtual stuff sucks in terms of code placement?
