C++: сомнения относительно шаблона посетителя

Question

Я знаю, какой шаблон посетителя и как его использовать; этот вопрос не является дубликатом этого one.

---

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

Часто мне нужно добавить функции в некоторые классы, но без добавления этих новых функций в библиотеку. Позвольте мне использовать реальный пример:

В этих библиотеках я получил класс Shape, унаследованный CircleShape, PolygonShape и CompositeShape.

Я сейчас разрабатываю графическое приложение, где мне нужно, чтобы сделать эти Shape, но не хочу, чтобы поставить виртуальную функцию render в классе ядра Shape, так как некоторые из моих проектов, которые используют Shape не делать какой-либо рендеринг и другие графические проекты могут использовать разные механизмы рендеринга (я использую Qt для этого проекта, но для игры я бы использовал OpenGL, поэтому функции render понадобятся разные реализации).

Самый известный способ сделать это с помощью Visitor Pattern, конечно, но это выскакивает некоторые сомнения в мой ум:

Любой класс любой библиотеки может понадобиться, чтобы быть продлен, как мой Shape делает. Большинство публичных библиотек (обо всех них) не предоставляют никакой поддержки шаблону посетителя; Зачем? почему я должен?

Шаблон посетителей - это способ имитации Double Dispatching в C++. Он не является родным на C++ и требует явного внедрения, что делает интерфейс класса более сложным: я не думаю, что функция applyVisitor должна быть на том же уровне функций моего класса, я вижу это как нарушение абстракции.

Явное повышение литья Shape с dynamic_cast дороже, но для меня это выглядит как более чистое решение.

---

Итак, что мне делать? Реализация Double Dispatching во всех моих библиотечных классах? Что делать, если библиотека, предоставляющая Shape, не была моей, но некоторая библиотека GPL найдена в Интернете?

Answer 1

Первое: «Посетитель шаблон является способ имитации Double Отправка на C++. " Это, вернее, не совсем правильно. На самом деле, двойная отправка - это одна из форм множественной отправки, которая является способом имитации (отсутствующих) мульти-методов на C++.

---

ли операции по иерархии классов должны быть реализованы с помощью добавления виртуальных функций или по добавляющих посетителей определяются вероятностями добавления классов против добавления операции:

• Если количество классов продолжает меняться быстрее t han количество операций, использование виртуальных функций. Это связано с тем, что добавление класса требует изменения всех посетителей.
• Если число классов является относительно стабильным по сравнению с числом операций, посетителей используют. Это связано с тем, что добавление виртуальной функции требует изменения всех классов в иерархии.

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

Однако с сторонними библиотеками есть еще один аспект: обычно пользователи не могут изменять классы в библиотеке.То есть, если им нужно добавить операцию, единственный способ, которым они могут сделать это путем добавления посетителя - , если библиотека предоставляет крючки для них, чтобы подключить в нее.
Итак, если вы пишете библиотеку и чувствуете, что пользователи должны иметь возможность добавлять к ней операции, то вам необходимо предоставить возможность подключить своих посетителей к вашему lib.

Answer 2

Это не похоже на случай для шаблона посещения для меня.

Я бы предположил, что у вас есть класс RenderableShape, который объединяет объект Shape, а затем создает подклассы для каждой фигуры. RenderableShape будет иметь виртуальный метод render.

Если вы хотите поддерживать несколько механизмов рендеринга, вы можете иметь базовый класс RenderContext, который абстрагирует операции рисования с подклассами для каждого механизма рендеринга, причем каждый подкласс реализует операции рисования с точки зрения его механизма рендеринга. Затем у вас есть RenderableShape::render взять RenderContext в качестве аргумента и нарисовать его с помощью абстрактного API.

Answer 3

Итак, есть класс xxxShape, который каким-то образом содержит информацию, которая «управляет» рендерингом. Для кругов, которые могут быть в центре, радиусе, для квадратов - некоторые угловые координаты или некоторые такие. Может быть, некоторые другие вещи о пломбах и цветах.

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

Но, по-видимому, у вас достаточно методов доступа общественности к классам, чтобы вы могли получить информацию о «вождении», иначе вы обречены.

Таким образом, в этом случае, почему вы можете не просто обернуть эти пункты:

CircleRenderer hasA Cicle, knows how to render Circles 

и так далее. Теперь используйте шаблон посетителя в классах Renderer.

Answer 4

Там через множество возможных решений, но вы можете сделать это, например: Начать новую иерархию, которая делает Shapes в определенном Context:

// contracts: 

class RenderingContext { 
public: virtual void DrawLine(const Point&, const Point&) = 0; 
    // and so on... 
}; 

class ShapeRenderer { 
public: virtual void Render(RenderingContext&) = 0; 
}; 

// implementations: 

class RectangleRenderer : public ShapeRenderer { 
Rectangle& mR; 

public: 
virtual void Render(RenderingContext& pContext) { 
    pContext.DrawLine(mR.GetLeftLower(), mR.GetRightLower()); 
    // and so on... 
} 

RectangleRenderer(Rectangle& pR) : mR(pR) {} 
}; 

Answer 5

Я понимаю, что вы сказали, и я разделяю те же проблемы. Проблема в том, что шаблон посетителя не очень четко определен, и исходное решение для него вводит в заблуждение, ИМХО. Вот почему так много вариаций этого шаблона.

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

Мне не нравятся реализации с визитом, посещение, посещениеВам, acceptA, acceptB, acceptWhatever. Это абсолютно неправильно, ИМХО.

Если у вас есть шанс, пожалуйста, взгляните на an article I've written about this.

Это Java, но вы можете легко переносить на C++, если найдете его полезным для своих целей.

Я надеюсь, что это помогает

Приветствия