Visitor Pattern

1. Usage

Adds new operations to existing object structure without modifying that structure. Separates an algorithm from an object structure on which it operates.

Example:
An example would be a guest visiting a household. A guest talks to each family member, but he talks to each one in a different way – he will not talk the same with adults as he will with children. The guest has indispensable knowledge of how to talk to certain household member. This knowledge however does not have an impact on the household.

2. UML class diagram

The Visitor can visit objects that don’t have a common parent class.

Although the ConcreteElement nodes may represent unrelated classes, they all should derive from a common Element base.

The client instantiates a ConcreteVisitor.

The traversal algorithm invokes Element::accept(Visitor) for each node.

The ConcreteElement calls Visitor::visit(ConcreteElement).

The ConcreteVisitor now uses the ConcreteElement interface to carry out node-specific tasks.

3. Pros

cleaner code – factors out type specific event handling from classes and centralises it in a Visitor

easy to add a new “operation” for all Visitable classes – an operation is implemented as a Visitor subclass with a handler method for each Visitable object type

can traverse multiple object types in the same traversal – unlike Iterator which can only traverse one type at a time

useful for running a variety of reports – without Visitor every class that you’d want to report on would have to have a custom method per report

4. Cons

if a new Visitable class is added, all Visitor subclasses have to be extended to support it