Паттерн Visitor. Продвинутое использование

А как же тогда называть такую практику? И куда помещать код, который находится в классе UpcastVisitor? Насчет существующего паттерна — покажите мне пожалуйста, где такое используется. Вы, возможно, не до конца поняли, что вся новизна находится в конце статьи, после длинной предыстории и объяснения того, зачем вообще нужно использовать visitor.

Ссылка на игру будет в следующей статье :)

Если у вас в программе большое количество visitor'ов (например 10), и половина из них будет пользоваться UpcastVisitor'ом, то кода будет меньше. Просто я пытался привести простой пример. В UpcastVisitor'e каждый метод всегда состоит всего из одной строчки, его не сложно добавить при создании нового класса.

Базовый Visitor всегда знает о всех классах иерархии. По крайней мере о всех листьях. Такой уж это паттерн. Традиционное применение — разделение объектов и алгоритмов для работы с ними. Переносить логику обратно в посещаемый объект противоречит самой идее паттерна.
Обход своих детей — это дополнительная фича, которой, наверное, часто пользуются. Но эта фича никак не противоречит и не мешает работе UpcastVisitor'а. Например, если бы дерево хранило все ветки:

class Tree
{
public:
    virtual void accept(Visitor& visitor)
    {
        for (int i = 0; i < m_branches.size(); ++i)
        {
            m_branches[i].accept(visitor);
        }
        visitor.visit(*this);
    }
    //...
};

Все прекрасно работает, UpcastVisitor посещает все объекты, как и планировалось.

«Разве это сложно?»
Это просто. Только после этого надо _не забыть_ — и это никак не лечится компилятором — добавить оверрайды там, где это нужно. Собственно, отсутствие поддержки компилятором — тоже недостаток этого паттерна.

«Обычно при наличии visitor'ов из классов иерархии выносится большая часть алгоритмов, в этом нет ничего необычного, затем он и нужен, этот паттерн.»
Я склонен думать, что он нужен для обратного — для того, чтобы не дублировать код обхода узлов. В этом его основной смысл. А для выноса алгоритмов используется паттерн «стратегия».

«Да, это вносит некоторую сложность, зато с лихвой окупается гибкостью. „
“Don't write smart code». Визитор — классический пример смарткода. Я сторонник простых решений, пусть даже для этого придется пожертвовать какой-то (чаще всего оказывающейся ненужной) гибкостью, потому что поддерживать это потом обычным людям. Паттерн «визитер» в поддержке очень дорог, это проверено личным опытом.

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

Если вы так напишете, то все перестанет работать, потому что именно из метода accept визитор получает информацию о типе объекта. А если написать painter.visit(*it), то будет вызываться заглушка из базового класса Visitor::visit(Object& object) и ничего не нарисуется.

Извините, не совсем вас понял. Где дублируется код?

Спасибо, обновил статью.

Разбухать будет только базовый класс Visitor и UpcastVisitor, все остальные визиторы будут реализовывать только то, что им нужно. Это абсолютно нормально.
Если я все правильно понял, вы хотите хранить в каждом объекте как минимум три стратегии — для отрисовки, создания и удаления. С таким подходом в реальном приложении при большом количестве объектов занимаемая память может увеличиться в несколько раз. Паттерн visitor лишен этого недостатка, т.к. в объекте ничего не хранится.
Также при добавлении нового типа стратегии вам нужно будет модифицировать все классы иерархии, добавляя в них вызовы метода этой стратегии. В случае использования паттерна visitor вам просто нужно будет создать новый тип visitor'а, что намного проще.

s/частичной специализацией/специализацией/

Вы пишете, что реализацию методов accept() можно вынести в отдельный файл visitor'a, а в вашем коде реализация в файле orange.cpp, не совсем понятно.
Если конечное действие происходит в посещаемом классе, то visitor не нужен, сойдет обычный виртуальный метод:

class Object
{
public:
    virtual void draw() = 0;
};

class Orange : public Object
{
public:
    virtual void draw() { puts("draw orange"); }
};

int main()
{
    Object* orange = new Orange();
    orange->draw();
    return 0;
}

Смысл visitor'а именно в том, чтобы вынести действие из посещаемого класса.

Поздравляю вас, если вы понимаете, что visitor и double dispatch это связанные вещи, то вы понимаете, как работает паттерн, хотя visitor — это не double dipatch. Правильнее говорить: «использует double dispatch» или «основан на double dispatch». Из википедии: «The visitor takes the instance reference as input, and implements the goal through double dispatch.»
Double dispatch сам по себе не подразумевает наличие иерархии, как посещаемых объектов, так и visitor'ов.
Простой пример double dispatch'а:

class Human
{
public:
    void eat(Apple& apple) { cout << "Yum-yum"; }
    void eat(Orange& orange) { cout << "Yum-yum-yuuuum!"; }
};

class Apple
{
public:
    void feed(Human& human) { human.eat(*this); }
};

class Orange
{
public:
    void feed(Human& human) { human.eat(*this); }
};

int main()
{
    Human human;
    Apple apple;
    apple.feed(human);
    Orange orange;
    orange.feed(human);
    return 0;
}

Как видим, тут нет базового класса visitor'a и базового посещаемого класса, а также ключевого слова accept. Вместо этого голый double dispatch :)