In Object Oriented Design, the visitor patter is one of the obscure pattern yet powerful enough to solve many complex OO scenarios. Visitor Pattern is also not really easy to understand at the first glance but you need to dig it around with practical examples. (I guess it’s not just for Visitor pattern but also for all the other patterns)
I would like to give a clean and simple introduction to visitor pattern with this post. So let’s start with a simple example ofthe usage of Visitor pattern
Visitor Pattern is often useful when there are fair numbers of related classes. One of the common examples of such a scenario is ‘drawing different shapes’. In this case we have a set of related classes; Circle, Trangle, Rectangle etc.
Now, if we are going to implement a draw() function for all these classes i.e. circle::draw(), trangle::draw().. etc we may be drawing different shapes but we are replicating a fair amount of code in all the classes. (Because the underlying methods, that we use to draw a ’shape’ is similar)
Visitor pattern is quite capable of solving this kind of scenarios. Here what we are doing is that we port all the draw methods of each shaped inherited classes (Circle, triangle, Rectangle) to one common class called ‘DrawVisitor’ or simply ‘Visitor’. Then in the ‘DrawVisitor’ we have a set of functions overloads based on the type of object passed to it (Circle, Triangle, Rectangle etc), which implements the ‘drawing logic’. And its obvious that since we use a single visitor class to do the drawing of shapes we can share whatever the resources that we want to draw and can reuse drawing code.
There are a lot of concerns about using Visitor pattern, because applying visitor pattern to a given scenario often makes things ambiguous. However the applicability of
Visitor pattern is justified by James Cooper (author of a Java companion to the GoF) by giving us a real world scenario which is essentially solvable only from visitor pattern. His primary example :
Suppose you have a hierarchy of Employee-Senior Manager-Vendor etc. They all enjoy a normal vacation day accrual policy, but, Senior Manger also participates in a “bonus” vacation day program. As a result, the interface of class SeniorManager(as well as ‘Vendor’ and ‘SecurityOfficer’) is different than that of class Employee. We cannot polymorphically traverse a Composite-like organization and compute a total of the organization’s remaining vacation days. This is how we use the visitor pattern to solve this problem.
- Create a ‘VacationVisitor’ which handles all the vacation manipulations and implementing different vacation manipulations in polymorphic visitor methods.
- Each visited instance (Employee, SeniorManager etc) is implementing an ‘accept’ method which in turns call the polymorphic visitor method.
- This method call procedure is termed as ‘Double Dispatch’
- The complete class design looks like this.
“The Visitor becomes more useful when there are several classes with different interfaces and we want to encapsulate how we get data from these classes.”
There are several motivations to use the visitor pattern.
- Add functions to class libraries for which the source is unrevealed or simple source is unavailable
- Obtain data from a distinct collection of unrelated classes and use it to present the results of a global calculation to the user program
- Gather related operations into a single class rather than force you to change or derive classes to add these operations
- Collaborate with the Composite pattern
.
