Декоратор и шаблон стратегии (против?) Для расширения функциональности - PullRequest
2 голосов
/ 25 июня 2010

Я пытался прочитать различные реализации Scene Graphs для разработки 3D-движка, чтобы изучить шаблоны проектирования, используемые в этой области, но, к сожалению, базы кода слишком велики для меня (пока, надеюсь).

Итак, допустим, у нас есть класс Model, в котором хранятся указатели на геометрию, шейдеры, текстуры и т. Д., И мы хотим разрешить анимацию каждого из элементов в отдельности, например, GeometryAnimator, TextureAnimator и т. Д., НоModel также может быть статическим.

Я вижу, что для достижения этой цели можно использовать как шаблон стратегии (без статических объектов), так и шаблон декоратора.Каковы преимущества / недостатки каждого в этом приложении?Или я слишком усложняю дела?

Спасибо за помощь!

Ответы [ 3 ]

2 голосов
/ 25 июня 2010

Простое, но в то же время прекрасное решение для этого заключается в создании интерфейсов / базовых классов abstact для всех различных вещей, которые может представлять узел сцены.

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;
    }   
};

На самом деле это тот подход, который высококлассные 3D-пакеты принимают в той или иной форме. С ним, для любого узла сцены, вы можете запросить его, поддерживает ли он определенный интерфейс (например, текстурный), а затем выполнить анимацию через него, например,

Maya и XSI делают это, но с помощью метода интерфейса, способного вернуть все интерфейсы, которые возвращают void *, которые клиент должен преобразовать соответствующим образом. Затем они создают ссылочные типы, которые скрывают требуемое приведение.

Вам не нужно всегда прибегать к классическим шаблонам проектирования для всех ваших программных решений. Рассматривайте их как инструменты и предложения, но всегда спрашивайте, какой шаблон проектирования подойдет для данной проблемы, не всегда приводит к самому простому решению. Вы должны думать сами, но шаблоны проектирования могут вам помочь.

1 голос
/ 25 июня 2010

Шаблон Decorator обычно используется для структур, которые нельзя изменить.Шаблон «Стратегия» может использоваться в структурах, которые вы полностью контролируете, но также позволяет другим изменять поведение без необходимости писать «вокруг», как декоратор.

0 голосов
/ 25 июня 2010

Я думаю, что вы слишком усложняете.Может быть, одного класса (модели) достаточно?Не забывайте заключать в капсулу только те вещи, которые меняются.

Если вы считаете, что этого недостаточно, стратегия в порядке.Например, если вы хотите использовать множество различных классов TextureAnimator и иметь возможность переключать их во время выполнения.

Шаблон декоратора похож на подклассы, но может выполняться во время выполнения (и поддерживает множественное наследование).Это также медленно (я думаю, вы кодируете игру).ИМО, это не решение.

В этом случае я бы написал один класс.Если бы мне понадобилась стратегия в будущем, я бы реорганизовал код.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...