Decorator vs Strategy Pattern (vs ?) to extend functionality

Question

Hi,

I've been trying to read through different implementations of Scene Graphs for 3D engine development to learn design patterns used in this domain, but unfortunately the code bases are too big for me grasp (yet, hopefully).

So, let's say we have a class Model that stores pointers to geometry, shaders, textures etc. and we want to allow animation of each of the members separately, say GeometryAnimator, TextureAnimator and so on, but a Model could also be static of course.

What I see is that both the strategy pattern (with no-op for static entities) and the decorator pattern could be used to achieve this. What are the benefits/drawbacks of each in this application? Or do I over complicate matters?

Thanks for your help!

Answer 1

The Decorator pattern is usually used for structures that can't be modified. The Strategy pattern can be used in structures that you control completely, but will also let you allow others to change the behavior without having to write "around" it, like a Decorator.

Answer 2

A simple yet perfectly fine solution for this is to establish interfaces/abstact base classes for all the various things that a scene node can represent.

class Texture
{
    ...
};

class Geometry
{
    ...
};

// etc

class SceneNode
{
public:
    // The following return null by default but
    // can be overriden by SceneNode subclasses
    // to return interface pointers.
    virtual Geometry* geometry()
    {
        return 0;
    }

    virtual Texture* texture()
    {
        return 0;
    }
};

class Model: public SceneNode, public Texture, public Geometry
{
public:
    // Override the functions of inherited interfaces

    virtual Geometry* geometry()
    {
        return this;
    }

    virtual Texture* texture()
    {
        return this;
    }   
};

This is actually the approach that high-end 3D packages take in some form or another. With it, given any scene node, you can query it if it supports a particular interface (ex: a texture one) and then do animation through that, e.g.

Maya and XSI do this but with an interface method capable of returning all interfaces that returns void* which the client has to cast accordingly. They then create reference types that hide the casting required.

You don't need to always resort to classic design patterns for all of your programming solutions. Consider them as tools and suggestions but always asking which design pattern would work for a given problem will not always lead to the most straightforward solution. You have to think for yourself but design patterns can help you.

Answer 3

I think that you over complicate. Maybe one class (Model) is sufficient? Remember to encapsulate only things that vary.

If you think it is not sufficient then strategy is ok. For example if you want to use many different TextureAnimator classes and be able to switch them in runtime.

Decorator pattern is like subclassing but can be done in runtime (and supports multiple inheritance). It is also slow (I guess you are coding a game). IMO this is not a solution.

In this case I'd code one class. If I needed strategy in the future I'd refactor the code.