It's been a while. Glad to see you are back.

When doing certain tasks that are tedious, difficult or just we are to exausted to do them; we often whish there was an altruistic someone to give as a hand and make them easier. Sometimes in this situations we would be ready to accept help from anybody, even from an strange visitor...


Visitor is a behavioral design pattern that intends to add or remove functionality from a class without changing its original implementation. It can help leverage complexity and also allows to keep concerns separated. Also is non intrusive, since will be only the clients choice to either allow the visitor to come by and provide support or not, by just calling a method.

Let's have a look at a bit of UML:

 

The only modification needed in the original class it to add a method that accepts a visitor.
That method will be called only by the client and the visitor to visit that class will also be provided by the client. The visitor just have a visit method that takes a concrete implementation of the class that has to visit. If you used the Visitable interface as parameter in visit method is not wrong but you will restrict the visitor to just what sees in the interface(In occasions can be desirable).

Now lets have a look at an example.
Here the Visitable interface and a couple of implementations:

 public interface FormulaOnePitOperation {  
   public void perform();  
   public void accept(Mechanic visitor);  
   public int dangerLevel();  
 } 

 public class PetrolFilling implements FormulaOnePitOperation{  
   private int petrolLevels;  
   public void perform() {  
     System.out.print("Filling the tank as we always do...");  
   }  
   public void accept(Mechanic visitor) {  
     visitor.visit(this);  
   }  
   public int dangerLevel() {  
     return petrolLevels;  
   }  
 } 

 public class WheelsReplacement implements FormulaOnePitOperation{  
   private int presureIndicator;  
   public void perform() {  
     System.out.print("Changing the wheels as we always do...");  
   }  
   public void accept(Mechanic visitor) {  
     visitor.visit(this);  
   }  
   public int dangerLevel() {  
     return presureIndicator;  
   }  
 }  

As we see in the above code, the visitor is passed in the parameter of the accept method that is used to trigger the visit.

Lets now have a look at the visitor's side

 public interface Mechanic {  
   public void visit(FormulaOnePitOperation formulaOnePitOperation);  
 } 

 public class PetrolPumpMechanic implements Mechanic {  
  public void visit(FormulaOnePitOperation formulaOnePitOperation) {  
     System.out.print("You are doing well guys keep going, I am just keeping an eye on the pump here. I won't disturb you");  
     if(formulaOnePitOperation.dangerLevel() > 100)  
       System.err.print("STOP!!! CLOSE THE PUMP NOW!!!!");  
   }  
 } 

 public class WheelsMechanic implements Mechanic{  
   public void visit(FormulaOnePitOperation formulaOnePitOperation) {  
     System.out.print("Just supervising the wheels replacement operation! Not disturbing");  
     if(formulaOnePitOperation.dangerLevel()>45)  
       System.out.print("Be careful you are pumping them too much");  
   }  
 }  

In the visitor side, the functionality of the FormulaOnePitOperation can be modified without changing any of the original code. Also another thing to notice in the above example is that since we are using the interface as parameter, we may be limmited to only use what is defined on it. In occasions is just enough and there is no need to access the concrete classes, but note that the UML diagram encorages to use the concrete implementations(In my personal opinion, I think there is not a big difference since the methods on the concrete classes could not be exposed publicly)

Now finally just the client class:

 public class Pit {  
   public static void main(String[] args) {  
     FormulaOnePitOperation petrolFilling = new PetrolFilling();  
     FormulaOnePitOperation wheelsReplacement = new WheelsReplacement();  
     petrolFilling.perform();  
     petrolFilling.accept(new PetrolPumpMechanic());  
     wheelsReplacement.perform();  
     wheelsReplacement.accept(new WheelsMechanic());  
   }  
 }  

Not much to say about the client, it just uses the classes as usual with the only difference that as per need now can pass a visitor to help add certain tasks. I mentioned at the beggining that Visitor is a non intrusive pattern, by this what I want to say is that nothing mandates the client to call a visitor if he doesn't want to.


A little dissadvantage that this patter has, both methods accept() and visit() have hardwired dependencies in their parameters that can make them hard to unit test.


          It's been a while. Glad to see you are back.

 

Pair programmers in action