When do we use visitor pattern

Use the Visitor when you need to perform an operation on all elements of a complex object structure for example, an object tree. The Visitor pattern lets you execute an operation over a set of objects with different classes by having a visitor object implement several variants of the same operation, which correspond to all target classes. Use the Visitor to clean up the business logic of auxiliary behaviors. The pattern lets you make the primary classes of your app more focused on their main jobs by extracting all other behaviors into a set of visitor classes.

Use the pattern when a behavior makes sense only in some classes of a class hierarchy, but not in others. You can extract this behavior into a separate visitor class and implement only those visiting methods that accept objects of relevant classes, leaving the rest empty.

Declare the element interface. This method should accept a visitor object as an argument. Implement the acceptance methods in all concrete element classes.

These methods must simply redirect the call to a visiting method on the incoming visitor object which matches the class of the current element. The element classes should only work with visitors via the visitor interface. Visitors, however, must be aware of all concrete element classes, referenced as parameter types of the visiting methods. You might encounter a situation where the visitor will need access to some private members of the element class.

You can treat Visitor as a powerful version of the Command pattern. Its objects can execute operations over various objects of different classes.

You can use Visitor to execute an operation over an entire Composite tree. You can use Visitor along with Iterator to traverse a complex data structure and execute some operation over its elements, even if they all have different classes. Hey, I have just reduced the price for all products. Check it out ». That's not the visitor pattern. Yes it is not. It just implemented in visitor pattern way which is wrong.

I had created a gist for visitor pattern example as per accepted answer. Add a comment. Active Oldest Votes. Improve this answer.

JacquesB JacquesB Because I can think suggested example as dir "path". AmitGupta: In your example, the same single method Head. You use the visitor pattern if you want different methods to be called for each type. JacquesB, No, Head. Hence I am calling Fileidentifier before passing file. So specific method can be called. AmitGupta: This will still lead to compiler to look for a single method with the signature of ReadableFile , and this will be called for all items in the list regardless of subtype.

AmitGupta: Cool. But in your gist the input to the traversal is a list of strings, not a list of different object instances. The visitor pattern is appropriate when you want to traverse a data structure containing objects of different types.

Show 6 more comments. The visitor pattern is a solution to a more general design problem: I have a hierarchy of different classes. We can add more classes, which must support all required operations. We can add more operations, which must be supported by all classes in the hierarchy. Extending by adding new operations We can't add new operations without editing the definitions of all classes.

This is useful in two cases: We cannot edit the original hierarchy because it's some external library. Need patience to read and understand it ; — Amit Kumar Gupta. Well explained. Each operation to be supported is modelled with a concrete derived class of the Visitor hierarchy. The visit methods declared in the Visitor base class are now defined in each derived subclass by allocating the "type query and cast" code in the original implementation to the appropriate overloaded visit method.

Add a single pure virtual accept method to the base class of the Element hierarchy. Each concrete derived class of the Element hierarchy implements the accept method by simply calling the visit method on the concrete derived instance of the Visitor hierarchy that it was passed, passing its "this" pointer as the sole argument.

Everything for "elements" and "visitors" is now set-up. When the client needs an operation to be performed, s he creates an instance of the Visitor object, calls the accept method on each Element object, and passes the Visitor object.

The accept method causes flow of control to find the correct Element subclass. Then when the visit method is invoked, flow of control is vectored to the correct Visitor subclass. The Visitor pattern makes adding new operations or utilities easy - simply add a new Visitor derived class. But, if the subclasses in the aggregate node hierarchy are not stable, keeping the Visitor subclasses in sync requires a prohibitive amount of effort.

An acknowledged objection to the Visitor pattern is that is represents a regression to functional decomposition - separate the algorithms from the data structures. If you don't want to enjoy the journey, check the table of contents on the left to skip to the juicy but that lays out the complete solution. A practical result of this separation is the ability to add new operations to existing object structures without modifying the structures.

Not modifying the structure is the key motivation here. If there are many or very different operations, implementing them on the involved types can easily overburden those with lots of unrelated functionality. And it's of course only possible to change these types in the first place if they don't come from a dependency. With the visitor pattern, each operation is implemented in a visitor that is then handed to the object structure, which passes its constituting objects to the visitor.

The structure is unaware of any specific visitor, so they can be freely created wherever an operation is needed. There are a bunch of things I would've done differently Car extends CarElement? Plenty more has been written about the visitor pattern use cases, prerequisites, implementation, limitations, etc.

Let's just assume that we're in a situation where it makes sense to use the pattern. Here's what to do instead.