Question

The question plot (a bit abstract, but answering this question will help me in my real app):

So, I have some abstract superclass for objects that can be rendered on the screen. Let’s call it IRenderable.

struct IRenderable {
  // (...)
  virtual void Render(RenderingInterface& ri) = 0;
  virtual ~IRenderable() { }
};

And suppose I also have some other objects that derive from IRenderable, e.g. Cat and Dog.

So far so good. I add some Cat and Dog specific methods, like SeekForWhiskas(...) and Bark(...). After that I add specific Render(...) method for them, so my code looks this way:

class Cat : public IRenderable {
public:
  void SeekForWhiskas(...) {
    // Implementation could be here or moved
    // to a source file (depends on me wanting
    // to inline it or not)
  }

  virtual void Render(...) {
    // Here comes the rendering routine, that
    // is specific for cats
    SomehowDrawAppropriateCat(...);
  }
};

class Dog : public IRenderable {
public:
  void Bark(...) {
    // Same as for 'SeekForWhiskas(...)'
  }

  virtual void Render(...) {
    // Here comes the rendering routine, that
    // is specific for dogs
    DrawMadDog(...);
  }
};

And then somewhere else I can do drawing the way that an appropriate rendering routine is called:

IRenderable* dog = new Dog();
dog->Render(...);

My question is about logical wrapping of such kind of code.

I want to break apart the code, that corresponds to rendering of the current object and it’s own methods (Render and Bark in this example), so that my class implementation doesn’t turn into a mess (imagine that I have 10 methods like Bark and of course my Render method doesn’t fit in their company and would be hard to find).

Two ways of making what I want to (as far as I know) are:

• Making appropriate routines that look like RenderCat(Cat& cat, RenderInterface* ri), joining them to render namespace and then the functions inside a class would look like
  virtual void Render(...) { RenderCat(*this, ...); }, but this is plain stupid, because I’ll lose access to Cat‘s private members and friending these functions looks like a total design disaster.

• Using visitor pattern, but this would also mean I have to rebuild my app’s design and looks like an inadequate way to make my code complicated from the very beginning.

Any brilliant ideas? 🙂

Answer 1

My understanding and recollection from when I dinked with graphic programming is the Visitor is indeed appropriate.