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

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

Кроме того, я использовал Visitor в языках, в которых не было перегрузки методов. Вы просто заменяете Visit(TypeN n) на VisitN(TypeN n).

Следите за комментариями.

Это псевдокод посетителя, и я не знаю, как бы я это сделал без сотрудничества с посещаемым объектом (по крайней мере, без блока переключателя):

abstract class ScriptCommand
{
   void Accept(Visitor v);
}

abstract class MoveFileCommand
{
   string TargetFile;
   string DestinationLocation;

   void Accept(Visitor v)
   {
      v.VisitMoveFileCmd(this);  // this line is important because it eliminates the switch on object type
   }
}

abstract class DeleteFileCommand
{
   string TargetFile;

   void Accept(Visitor v)
   {
      v.VisitDeleteFileCmd(this); // this line is important because it eliminates the switch on object type

   }
}

// etc, many more commands

abstract class CommandVisitor
{
   void VisitMoveFileCmd(MoveFileCommand cmd);
   void VisitDeleteFileCmd(DeleteFileCommand cmd);
   // etc
}

// concrete implementation

class PersistCommandVisitor() inherits CommandVisitor
{
   void VisitMoveFileCmd(MoveFileCommand cmd)
   {
      // save the MoveFileCommand instance to a file stream or xml doc
      // this code is type-specific because each cmd subtype has vastly
      // different properties
   }

   void VisitDeleteFileCmd(DeleteFileCommand cmd)
   { 
      // save the DeleteFileCommand instance to a file stream or xml doc
      // this code is type-specific because each cmd subtype has vastly
      // different properties
   }

}

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

Что касается посетителя, занимающегося перечислением, я думаю, что вы ограничиваете себя таким образом. Это не означает, что взаимодействующий класс (абстрактный VisitorEnumerator) не может быть задействован.

Например, обратите внимание, что этот посетитель не знает порядка перечисления:

class FindTextCommandVisitor() inherits CommandVisitor
{
   string TextToFind;
   boolean TextFound = false;

   void VisitMoveFileCmd(MoveFileCommand cmd)
   {
      if (cmd.TargetFile.Contains(TextToFind) Or cmd.DestinationLocation.Contains(TextToFind))
         TextFound = true;
   }


   void VisitDeleteFileCmd(DeleteFileCommand cmd)
   { 
      // search DeleteFileCommand's properties
   }

}

И это позволяет повторно использовать его следующим образом:

ScriptCommand FindTextFromTop(string txt)
{
   FindTextCommandVisitor v = new FindTextCommandVisitor();
   v.TextToFind = txt;
   for (int cmdNdx = 0; cmdNdx < CommandList.Length; cmdNdx++)
   {
      CommandList[cmdNdx].Accept(v);
      if (v.TextFound)
         return CommandList[cmdNdx];  // return the first item matching
   }
}

и перечислить наоборот с тем же посетителем:

ScriptCommand FindTextFromBottom(string txt)
{
   FindTextCommandVisitor v = new FindTextCommandVisitor();
   v.TextToFind = txt;
   for (int cmdNdx = CommandList.Length-1; cmdNdx >= 0; cmdNdx--)
   {
      CommandList[cmdNdx].Accept(v);
      if (v.TextFound)
         return CommandList[cmdNdx];  // return the first item matching
   }
}

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

Место, где посетитель особенно полезен, — это то, где посетителю нужно включить тип посетителей, и по какой-то причине вы не хотите кодировать это знание в посетителях (подумайте о архитектуре плагинов). Рассмотрим следующий код Python:

Стиль посетителя

class Banana(object):
      def visit(self, visitor):
          visitor.process_banana(self) 

class Apple(object):
      def visit(self, visitor):
          visitor.process_apple(self) 

class VisitorExample(object):
      def process_banana(self, banana):
          print "Mashing banana: ", banana

      def process_banana(self, apple):
          print "Crunching apple: ", apple

(Обратите внимание, что мы можем сжать логику посетителя с помощью базового класса/примеси).

Сравнить с:

Стиль без посетителей

class NonVisitorVisitor(object):
      def process(self, fruit):
          verb = {Banana: "Mashing banana: ", 
                  Apple: "Crunching apple: "}[type(fruit)]
          print verb, fruit

Во втором примере фрукты не нуждаются в специальной поддержке «посетителя», а «посетитель» обрабатывает отсутствие логики для данного типа.

Напротив, в Java или C++ второй пример на самом деле невозможен, и метод посещения (в посетителях) может использовать одно имя для ссылки на все версии метода процесса; компилятор выберет версию, которая относится к передаваемому типу; и посетитель может легко предоставить реализацию по умолчанию для корневого класса для типа посетителей. Также необходимо иметь метод посещения в посетителях, потому что вариант метода (например, process(Banana b) против process(Apple a)) выбирается во время компиляции в коде, сгенерированном для метода посетителя visit.

Соответственно, в таких языках, как Python или Ruby, где нет диспетчеризации по типам параметров (точнее, программисту приходится реализовывать ее самому), шаблон посетитель не нужен. В качестве альтернативы можно сказать, что шаблон посетителя лучше реализован без диспетчеризации через методы посетителя.

В целом, в динамических языках, таких как Python, Ruby или Smalltalk, лучше, чтобы классы «посетителей» содержали всю необходимую информацию (здесь применим глагол) и, при необходимости, предоставляли крючки для поддержки «посетителя», например в качестве командных или стратегических паттернов или используйте паттерн «Не посетитель», показанный здесь.

Вывод

Non-Visitor — это чистый способ реализации логики переключения типов, несмотря на то, что явное переключение типов обычно является запахом кода. Помните, что в Java и C++ для этого также используется явное переключение в посетителе; элегантность шаблона в этих языках заключается в том, что он позволяет избежать явной логики переключения в посетителях, что невозможно в динамических языках с нетипизированными переменными. Соответственно, шаблон «Посетитель» вверху плох для динамических языков, потому что воспроизводит грех, которого шаблон «Посетитель» пытается избежать в статических языках.

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

Обновление: вот рубиновая статья о реализации этого шаблона: http://blog.rubybestpractices.com/posts/aaronp/001_double_dispatch_dance.html

Двойная отправка кажется мне довольно вынужденной; Вы могли бы просто покончить с этим, насколько я могу судить.

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

Если я могу работать с семейством разнородных объектов и вызывать их общедоступные методы без какого-либо сотрудничества с "посещенным" классом, заслуживает ли это того, чтобы называться "шаблоном посетителя"?

и

написать новый класс, который манипулирует вашими объектами извне для выполнения операции"?

вы определяете, что такое двойная отправка. Конечно, паттерн Посетитель реализуется двойной диспетчеризацией. Но есть еще кое-что в самом узоре.

• Каждый посетитель представляет собой алгоритм для группы элементов (сущностей), и новые посетители могут быть подключены без изменения существующего кода. Принцип «открыто/закрыто».
• Когда новые элементы добавляются часто, лучше избегать шаблона «Посетитель».

Возможно, это зависит от языка.

Шаблон посетителя решает проблемы двойной и множественной иерархии в языках, не поддерживающих множественную отправку. Возьмите Ruby, Lisp и Python. Все они являются языками с динамической типизацией, но только CLOS-Lisp реализует в стандарте множественную диспетчеризацию. Это также называется мультиметодами, и Python и Ruby, по-видимому, могут реализовать его с помощью расширений.

Мне нравится любопытный комментарий к википедии, в котором говорится, что:

Объектная система Лиспа [CLOS] с ее множественной диспетчеризацией не заменяет шаблон Посетитель, а просто обеспечивает его более сжатую реализацию, в которой шаблон практически исчезает.

В других языках, даже в статически типизированных, приходится обходиться без мультиметодов. Шаблон Посетитель является одним из таких способов.

Шаблон посетителя для меня означал добавление новых функций к объектам в зависимости от их типа. По-видимому, иметь лестницы if/else для выполнения операций, специфичных для типа, плохо (мне нужно объяснение этого :( ). В python я смог сделать это, без всей драмы двойной отправки, с помощью monkeypatching (еще одна плохая идея) определенные функции как методы класса.

Я спросил об этом здесь.

В приведенном ниже примере предположим, что есть базовый класс ASTNode и большая иерархия классов под ним (ASTVar, ASTModule, ASTIf, ASTConst и т. д.). Эти классы имеют только свои определенные атрибуты данных и тривиальные методы.

Затем предположим, что код класса заблокирован (или, возможно, функциональность отделена от данных). Теперь у меня есть методы, которые динамически назначаются классам. Обратите внимание, что в приведенном ниже примере имя вызова метода итерации/рекурсии (stringify) отличается от имени функции (nodeType_stringify).

def ASTNode__stringify(self):
    text = str(self)
    for child in self.children:
            text += ", { " + child.stringify() + " }"
    return text

def ASTConst__stringify(self):
    text = str(self)
    for child in self.children:
            text += ", [ " + child.stringify() + " ]"
    return text

def ASTIf__stringify(self):
    text = str(self)
    text += "__cond( " + self.op1.stringify() + ")"
    text += "__then { " + self.op2.stringify() + "}"
    text += "__else {" + self.op3.stringify() + "}"
    return text

Я могу расширить классы (возможно, один раз во время инициализации модуля) функциональностью, когда захочу (плохая идея?).

# mainModule1.py
def extend_types():
    # ASTNode and all derived class get this method
    ASTNode.stringify = ASTNode__stringify
    ASTConst.stringify = ASTConst__stringify
    ASTIf.stringify = ASTIf__stringify

Теперь вызов my_root_node.stringify() будет соответствующим образом вызывать правильные дочерние методы (рекурсивно), без явной проверки типа.

Разве этот метод не похож на добавление методов к прототипам Javascript (шаблон посетителя в JS< /а>).

Шаблон посетителя делает 2 вещи:

• Допускает специальный полиморфизм (одна и та же функция, но разные действия для разных «типов»).
• Позволяет добавить новый алгоритм потребления без смены поставщика данных.

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