Visitor
| Line 36: | Line 36: | ||
#Adding a new ConreteElement is difficult | #Adding a new ConreteElement is difficult | ||
#Elements may expose otherwise private attributes | #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 [http://www.objectmentor.com/resources/articles/acv.pdf 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. | ||
Revision as of 05:44, 5 October 2008
Contents |
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.
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
Consequences
Benefits
- Adding new operations is easy. Just add a new Visitor class
- Separates unrelated behaviours and gathers related ones
- Visit across more than one class hierarchy
Liabilities
- Adding a new ConreteElement is difficult
- 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.
