The Visitor Pattern

1. The Visitor Pattern SE-2811 Dr. Mark L. Hornick

2. Visitor pattern context Problem • Different operations (algorithms) need to be performed on an object structure • the object structure may be a composite hierarchy but any structure is applicable Solution • Define operations as separate classes without changing the classes on which the operations are carried out • That is, implement algorithms as classes – these classes are known as Visitors

3. Computer Builder visitor example Structure • Computer System as a collection of Components (Parts & Composites) Operations • Compute total price • Compute power consumption • Compute total weight

4. Example – no Visitor SE-2811 Dr. Mark L. Hornick

5. Example with Visitor SE-2811 Dr. Mark L. Hornick

6. Simple Visitor The Client creates a Visitor to acquire information from Elements controlled by the Client. The Client “introduces” the Visitor to each element (by calling an Element’s accept() method passing a Visitor reference to the Element. Only a single ConcreteElement is shown here – the simplest case of a hierarchy. Note that the Element interface must be modified to accommodatea Visitor.Also, a ConcreteElement must provide public methods that the Visitor can invoke in order to perform its operations This ConcreteVisitor is designed to perform only one specific function for each ConcreteElement it visits (e.g. computing the element’s cost). The ConcreteVisitor often keeps a running tab on data it gathers from all visited elements. SE-2811 Dr. Mark L. Hornick

7. UML Note that each Visitor has specific methods that target each type of ConcreteElement to be visited. Note that the object hierarchy may implement the Composite pattern (but this is not required). The Client knows how to traverse the hierarchy and “introduce” the Visitor to each element Note that each ConcreteElement provides a specific public method that the Visitors invoke in order to perform their operations

8. Collaborations ConcreteElementA Client ConcreteElementB aVisitor=new ConcreteVisitorA() ConcreteVisitorA accept(aVisitor) visitConcreteElementA(this) operationA() getResultA() accept(aVisitor) visitConcreteElementB(aConcreteElementB) operationB() getResultB()

9. Advantages • Visitor makes adding new operations relatively easy • If a new operation over the object structure is needed, just create another type of ConcreteVisitor • Each Visitor gathers related operations and separates unrelated ones. • Unrelated behaviors are implemented in their own Visitors.

10. Disadvantages • A lot of code has to be written to prepare for the Visitor pattern: • The Visitor class/interface with one abstract “visit_xxx” method per ConcreteElement class to be visitedmust be defined. • An accept() method has to be added to each ConcreteElementclass to be visited • Public methods must be provided on each ConcreteElement to provide Visitor access • Arguments and the return type of visit_xxx() methods have to be known in advance • ConcreteElements must be modified to accommodate the pattern as well • Encapsulation is compromised – public methods must be provide sufficient access to ConcreteElement to let the Visitor perform its function; thereby exposing internal implementation • The code is more obscure