in my program architecture, the nodes of a scenegraph are recursively updated through an update() function from the node abstract base class. also implemented from the node abstract base class is a recursive draw() function. in early mockups, from within the draw() function, i drew directly to a reference of the GL object. now, i am ready to build a render queue to store drawing requests, so that they may be grouped to minimize state change, and otherwise optimized. in addition, i want to decouple the drawing from the renderer reference, or interface. that is, i want to create a request to draw a line ( with some parameters ), then follow with some vertices for the line without knowing anything about the renderer. i want to avoid this:
draw()
{
gl.glBegin(GL.GL_LINE_STRIP);
[snip]
}
- or -
draw()
{
Renderer.line() // code to interface, which in turn, calls gl.glBegin( GL.GL_LINE_STRIP ) somewhere downstream
// this is good, but it means that i'm tied to an interface now
// may not be a bad thing, but it seems that it would make refactoring
// otherwise hot rodding my renderer implementation more dangerous
// should i just relax and trust refactoring tools?
}
i want the ability to upgrade and modify my renderer implementation ( or even swap it out for another ), without having to maintain a series of versioned interfaces ( Renderer1.0, Renderer1.1, etc. ). so, my first idea was to encapsulate the request in an object similar to this signature:
public abstract class RenderCommand
{
private Renderer r;
public abstract void doCommand();
public RenderCommand( Renderer r ) { this.renderer = r; }
{
while this pattern eliminates the need for a node to know which commands are supported, or implemented, it would mean that RenderCommand subclasses would have to either a) implement the command ( talk to the GL reference and make it do stuff ), or b) call a Renderer interface. that would just move my design problem from the node to the render command. while i wouldn’t have to manage and maintain the Renderer interface so strictly as it would be hidden, if there were changes to the Renderer interface, i would possibly have to go in and update all the RenderCommand subclasses to take advantage of new features, or work around deprecated ones.
how can a renderable object request a drawing operation, without knowledge of the renderer, or its interface methods? further, after a requested drawing operation has been sorted and stored in an optimized render queue, how can that operation later trigger an appropriate method in the renderer interface short of interpreting code, parsing text, or anything else that might have a performance penalty associated.
perhaps i’m just not looking at the problem correctly, or i’m being lazy abount writing a big interface, but , thanks in advance for any comments, questions or suggestions.
edit: since there is a very large chance that i may have misunderstood the available literature on certain design patterns, please let me know if one of these patterns might be what i’m looking for:
Command pattern
Bridge Pattern
Strategy Pattern
