Это интересная идея. Однако я не собираюсь давать вам название уже установленной модели здесь, напротив, я собираюсь объяснить (несколько), почему я не думаю, что она уже есть.
Что это делает?
Это очень хороший способ избежать наследства ужасного алмаза.
Поскольку существует определенная путаница относительно цели метода, позвольте мне пояснить, почему я считаю, что это его цель:
class RefCounted
{
virtual void addReference() = 0;
virtual void removeReference() = 0;
};
class B: public RefCounted {};
class C: public RefCounted {};
class Diamond: public B, public C {};
Теперь у нас есть проблема. Если мы поместим реализацию RefCounted прямо в этот класс, он станет базовым классом, а не интерфейсом, и, следовательно, мы должны использовать виртуальное наследование, иначе члены данных будут дублированы (присутствуют как в B, так и в C).
Таким образом, идея состоит в том, чтобы отложить реализацию до последнего момента.
Преимущества:
- Не нужно пытаться угадать использование B или C: там нет необходимости в виртуальном наследовании.
- Компилятор приятно напомнит вам, если вы забудете добавить реализацию, так что вам не нужно об этом беспокоиться.
Неудобная:
- Возложите бремя на клиента: вам лучше иметь фабрику для создания ваших объектов, тем более что один объект может реализовывать различные интерфейсы !!! Обратите внимание, что это может быть автоматизировано с помощью шаблонного метапрограммирования (более или менее) или может быть просто предоставлено автором класса.
Пример предоставления:
// d.h
class D: public B, public C
{
public:
typedef ImplementRC<D> concrete_type;
static concrete_type Build(int, int); // Named Constructor idiom
private:
D(int,int);
}; // class D
// main.cpp
D::concrete_type myD = D::Build(1,2);
Так как зовут?
Я не могу придумать ничего, что точно соответствует этому. Были упомянуты Bridge и Decorator, но это совершенно особенное, и на самом деле не настолько ОО-ориентированное (например, это не произойдет в Java, поскольку у вас нет Multi-Inheritance), поэтому я сомневаюсь, что этот термин будет найден в книге ГФ.
Кроме того, на самом деле это не CRTP, потому что в CRTP есть своего рода цикл (основа знает о его производном классе), которого здесь не бывает> мы действительно строго линейны!
И, конечно же, это не идиома Pimpl, которая предлагает скрыть реализацию от клиента, а при использовании шаблона для реализации просто бросить его в лицо! (Шаблон может использовать Pimpl в качестве внутренней детализации)
Я скромно предлагаю jiti для Just In Time реализации , которая каким-то образом подражает названию, но ближе к сути, я думаю, деривация здесь - это всего лишь инструмент, а не цель .
Интересная идея в любом случае.