Почему использование Шаблон "посетитель"? [дубликат]

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

, Если у меня есть иерархия (или дерево), каждый Узел имеет список детей. Когда я хочу применить процесс к каждому узлу в дереве, приятно создать Посетителя.

Узел А может тогда применить Посетителя себя и каждый из его дочерних Узлов. Каждый ребенок, transitively, делает то же (примените Посетителя себя и затем любых детей).

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

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

Шаблон "посетитель" является взломом для языков, которые не поддерживают, несколько диспетчеризируют непосредственно (язык как C++, и Java только поддерживают единственную отправку на основе объекта. Несколько диспетчеризируют, поддерживается CLOS). В этом случае, если Вы хотите, чтобы и счет и Клиент были полиморфными, необходимо будет использовать два интерфейса, BillVisitor и Клиента на единственных языках отправки. Например: реализация принимает, обычно:

void accept(BillVisitor visitor) { visitor.bill(this); } // java syntax

Уведомление здесь, и Customer#accept и BillVisitor#bill может быть переопределено их соответствующими подклассами, получающейся очень богатой комбинацией поведения во время выполнения, которое не может быть достигнуто иначе. Это - действительно надмножество того, что большинство других людей описало здесь как замену закрытия для применения функциональности к сложным структурам данных.

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

В моем приложении CAD/CAM у меня есть Пути и Наборы Путей (PathList). Иногда я должен генерировать набор форм. Не только я должен генерировать этот конкретный набор форм, я должен включать его с другим набором форм. Мне часто нужна дюжина или больше параметров для передачи всей информации, должен был сделать вычисления.

Все вычисления формы (простой или сложный) в моем CAM направляются PathList, который отослан в различные машины.

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

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

, Таким образом, Кухонный Посетитель Капота может, имел 8 форм к Pathlist

, В то время как Кухонный Посетитель Счетчика добавляет 6 форм.

Посетитель секции добавляет еще много.

Тогда я раздаю получающийся PathList к остальной части системы как любой другой генератор формы.

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

получающийся код очень читаем, который важен, когда я имею, пересматривают эту область 3, 5, или 10 лет по линии. Кроме того, из-за изменений инкапсуляции в одном посетителе имеют минимальный если любое влияние на других посетителей.

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

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

, Но в конечном счете это сводится к суждению и предпочтению.

В обоих случаях посетитель разделяется от потребительского класса. Преимущество состояло бы в том, если бы Вы хотели абстрагировать посетителя от класса вызывающей стороны также. Во втором случае класс вызова должен знать о тарификации. У Вас могла вместо этого быть другая стандартная программа где-нибудь, которая возвратит IVisitor. Код вызова мог тогда назвать Пользовательским. Примите (IVisitor) и не знайте что-либо о том, что делает посетитель.

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