посетитель — Создание инкапсулированной, но расширяемой библиотеки анимации в Stack Overflow

Я строю библиотеку анимации в C ++. Библиотека будет включать систему моделирования и рендеринга сцен. Требования системы

1. Разделение моделирования и рендеринга. Информация о состоянии сцены должна храниться отдельно от процедур рендеринга сцены.
2. Расширяемое моделирование и рендеринг. Если библиотека сама определяет node класс, пользователь библиотеки должен иметь возможность определить новый тип custom_node что расширяет функциональность node (возможно, по наследству, но, возможно, с помощью других средств). Затем пользователь должен иметь возможность указать пользовательскую процедуру для рендеринга custom_node, При этом пользователь должен каким-то образом иметь возможность воспользоваться процедурами рендеринга, уже присутствующими в библиотеке. Пользователь также должен иметь возможность определять новые процедуры для рендеринга библиотечных узлов. прибавление: пользователь должен иметь возможность определять целые системы рендеринга и выбирать, какую из них использовать для рендеринга сцены. Предположим, например, что библиотека включает в себя фотореалистичную систему рендеринга, но пользователь хочет рендерить сцены с помощью базовой схемы рендеринга. Пользователь должен иметь возможность реализовать такой рендерер, используя общий интерфейс рендеринга, который библиотека анимации использует под капотом во время цикла анимации (рендеринг кадра, обновление сцены, рендеринг следующего кадра и т. Д.).
3. Инкапсуляция библиотеки. Расширить функционал библиотеки до кастома nodes и процедуры рендеринга, пользователь не должен редактировать основной код библиотеки.

Неудачный подход: используйте дерево nodes как модель сцены. Подкласс node сделать новые типы узлов. Поскольку типы дочерних элементов узла могут быть неизвестны до времени выполнения, дочерние элементы узла хранятся в vector<std::shared_ptr<node>>,
Также определите верхний уровень renderer класс и подкласс renderer обеспечить конкретные виды рендеринга.

class image;

class node {
virtual image render(renderer &r) {return r.render(*this);}
std::vector<std::shared_ptr<node>> children;
std::weak_ptr<node> parent;
// ...
}

class renderer {
image render(node &n) {/*rendering code */}
// ...
}

Для рендеринга сцены определите рендерер

renderer r{};

и пройдитесь по дереву узлов вашим любимым методом обхода. Когда вы сталкиваетесь с каждым std::shared_ptr<node> n, вызов

n->render(r);

Этот подход разделяет моделирование и рендеринг и обеспечивает расширяемость. Чтобы создать custom_nodeПользователь библиотеки просто подклассы node

class custom_node : public node {
virtual image render(renderer &r) override {return r.render(*this)}
}

Этот подход работает нормально, пока мы не попытаемся предоставить пользовательские средства рендеринга custom_node, Для этого мы пытаемся создать подклассы renderer и перегрузка render метод:

class custom_renderer : public renderer {
image render(custom_node &n) {/*custom rendering code*/}
}

Само по себе это не работает. Рассматривать:

renderer &r = custom_renderer{};
std::shared_ptr<node> n = std::make_shared<custom_node>{};
n->render(r); // calls renderer::render(node &)

Для вызова custom_renderer :: render (custom_node &n) при желании нам нужно добавить виртуальную перегрузку к нашему исходному классу рендерера:

class renderer {
image render(node &n) {/*rendering code */}
virtual image render(custom_node &n) = 0;
}

К сожалению, это разрушает инкапсуляцию библиотеки, потому что мы отредактировали один из классов библиотеки.

Как же тогда мы можем разработать систему, которая удовлетворяет всем 3 требованиям?