Visitor

Revision as of 09:16, 7 October 2008

Introduction

The Visitor is a behavioural pattern. It allows the designer to define new operations on an object structure and its elements, without modifying the object structure itself.

Structure

The Visitor describes the relations between three distinct classes:

• ObjectStructure - Provides a visitor with access to its elements
• Element - Accepts visits.
• Visitor - Accesses an element to perform operations.

Figure 1 graphically describes these Visitor pattern relationships.

Figure 1: A UML 2.1 class diagram describing the Visitor structure

Communication

The Visitor pattern allows a visitor object to access and perform operations on an element object. A summary of the Visitor pattern communications is given in Fig. 2. Here the following interactions are shown:

• Sequence 1 - The object aVisitor1 performs an operation on anElementA
• Sequence 2 - The object aVisitor2 performs an operation on anElementB
• Sequence 3 - The object aVisitor1 performs an operation on anElementA
• Sequence 4 - The object aVisitor2 performs an operation on anElementB

Figure 2: A UML 2.1 communication diagram describing the interactions between objects in the Visitor pattern

Consequences

Benefits

1. Adding new operations is easy. Just add a new Visitor class
2. Separates unrelated behaviours and gathers related ones
3. Visit across more than one class hierarchy

Liabilities

1. Adding a new ConreteElement is difficult
2. Elements may expose otherwise private attributes

Conflicts

The Acyclic Dependencies Principle

The Visitor pattern conflicts with the Acyclic dependencies principle. Here, the concrete visitor depends on the interface of the concrete elements it visits. Similarly, the concrete elements must be familiar with interface of all visiting concrete visitors.

Mitigation

• Where a visitor pattern is necessary, the ill effects of cyclic dependency can be mitigated by ensuring that cyclically dependent classes are deployed within the same package.
• Bob Martin suggests a solution to this problem in his paper Acyclic Visitor. This solution uses casting to move the dependency from the interface of the concrete elements to the implementation. The abstract element is designed to depend on the abstract visitor, within a concrete element's implementation, down-casting is used to extract and consume the concrete visitor's interface.

See also

• A froggy visitor