Visitor Design Pattern Example

Visitor pattern is a behavioral pattern that lets you define a new operation to apply toward classes of the elements (Element Class, a.k.a. Visitable Class) without changing the classes of the elements on which it operates. The new operations are grouped together each is called a separate Visitor class.

overview

Visitor pattern lets you add a new operation to a structure of objects (Visitable/Elements) to be traversed through, without changing the Visitable/Element on which it operates.

Visitor class separates out would-be virtual functions into a Visitor class. 

Each Visitable/Element should implement an accept(Visitor) function which delegate the request to the underlying Visitor class via calling visitor.visit(this) from accept(Visitor).

Each concrete Visitor class implements a set of visit(Object) functions that does the real work for the operation to be applied to the structure of objects. Each visit(Object) function takes in a different type of concrete Visitable/Element object. The Visitor can optionally maintain a context during a traversal.

source: GoF

Notes: 

1. Same operations (VisitConcreteElementX()) applied to different Elements are grouped into the same Visitor.
2. In each concrete visitor class, the VisitConcreteElementX() is not limited to apply to element of the same base type.
   
3. Visitor class may even hold local state.

scenario

Consider a compiler program that deals with an abstract syntax tree. Each node in the abstract syntax tree may be a variable, an assignment, arithmetic expression, etc. For each node element, you want to apply operations like type-checking, code optimization, pretty-formatting, etc.

One way of structuring the above is to have a node class hierarchy. Within node class hierarchy, for each different node class, you define its type-checking operation, code optimization operation, and pretty-formatting operation inside the node class. This has three potential drawbacks:

1. Adding a new operation requires adding the code to every applicable node class, probably all node classes, which requires all node classes to be recompiled.
2. Adding a new operation to all node classes may call for redefining the interface of the node classes, which is potentially costly.
3. Confusion, because similar operations for different node classes are not grouped together.

To avoid the above drawbacks, apply the Visitor pattern which defines two class hierarchies: one (the visitable Element hierarchy) for the nodes or data structure being operated on and one  (the Visitor hierarchy) for defining operations to be applied to the elements. The delegation of the operation from an element class to a visitor class is through an accept(Visitor) function defined in the element class.  Then in terms, calls into Visitor.visit(this). When you need to introduce a new type of operation, you'd create a new subclass in the Visitor hierarchy, without needing to modify the Element hierarchy.

visotor pattern code sample

The element/visitable interface simply defines an accept method to allow the visitor to run some action over that element - the ConcreteElement will implement this accept method. 

// Element Interface
public interface Visitable{
    public void accept(Visitor visitor); // 1
}


// Concrete element
public class Book implements Visitable {
    private double price;
    private double weight;

    //accept the visitor
    public void accept(Visitor vistor) {
        visitor.visit(this);
    }

    public double getPrice() {
        return price;
    }

    public double getWeight() {
        return weight;
    }
}

public interface Visitor {
    public void visit(Book book);
    public void visit(CD cd);
    public void visit(DVD dvd);
}

public class PostageVisitor implements Visitor {
    private double totalPostageForCart;   // 2

    //collect data about the book
    public void visit(Book book) {
        //assume we have a calculation here related to weight and price
        //free postage for a book over 10
        if (book.getPrice() < 10.0) {
            totalPostageForCart += book.getWeight() * 2;
        }
    }

    //add other visitors here
    public void visit(CD cd){
        ...
    }

    public void visit(DVD dvd){
        ...
    }

    //return the internal state
    public double getTotalPostage(){      // 3 
        return totalPostageForCart;
    }
}

[1] Delegate operation applied to an element to a corresponding visitor class.
[2] Visitor class holds local state. In this case, to accumulate postage cost.
[3] Request the result of the operation/computation/local state.

comparison

Visitor Pattern vs. Non-Visitor Pattern

• In Visitor Pattern, introducing an operation (by introducing a new Visitor subclass) is easy, but adding an element (by introducing one new operation for each Visitor class) is hard. 
  
• In Non-Visitor Pattern, introducing an operation (by introducing a new operation for each element class) is hard, but adding an element (by introducing one new element subclass) is easy. 

when to use visitor pattern

Choose to use Visitor pattern if:

1. you want to separate out would-be virtual functions;
   
2. you're more likely to introduce new operations and less likely to introduce new elements;
   
3. you need to introduce new operation to apply to elements, but you have no access to the source code of the element hierarchy;
4. it is possible to prepare your domain model to be able to accept visitors.

references

• Design Patterns Uncovered: The Visitor Pattern
  
• Notes, Experiences and Opinions by Richard Gomes
• Multiple dispatch (and poor men's patter matching) in Java