Visitor design pattern is one of the behavioral design patterns. It is used when we have to perform an operation on a group of similar kind of Objects. With the help of visitor pattern, we can move the operational logic from the objects to another class.
The visitor pattern consists of two parts:
- a method called Visit() which is implemented by the visitor and is called for every element in the data structure
- visitable classes providing Accept() methods that accept a visitor
UML Diagram Visitor design pattern
- Client : The Client class is a consumer of the classes of the visitor design pattern. It has access to the data structure objects and can instruct them to accept a Visitor to perform the appropriate processing.
- Visitor : This is an interface or an abstract class used to declare the visit operations for all the types of visitable classes.
- ConcreteVisitor : For each type of visitor all the visit methods, declared in abstract visitor, must be implemented. Each Visitor will be responsible for different operations.
- Visitable : This is an interface which declares the accept operation. This is the entry point which enables an object to be “visited” by the visitor object.
- ConcreteVisitable : These classes implement the Visitable interface or class and defines the accept operation. The visitor object is passed to this object using the accept operation.
Let’s see an example of Visitor design pattern in Java.
Book ISBN::1234 cost =20 Book ISBN::5678 cost =95 Banana cost = 20 Apple cost = 25 Total Cost = 160
Here, in the implementation if accept() method in all the items are same but it can be different. For example there can be logic to check if item is free then don’t call the visit() method at all.
- If the logic of operation changes, then we need to make change only in the visitor implementation rather than doing it in all the item classes.
- Adding a new item to the system is easy, it will require change only in visitor interface and implementation and existing item classes will not be affected.
- We should know the return type of visit() methods at the time of designing otherwise we will have to change the interface and all of its implementations.
- If there are too many implementations of visitor interface, it makes it hard to extend.
Another example of visitor pattern in C++
Apple::buy m_num_apple 1 Google::buy m_num_google 1 Google::buy m_num_google 2 Apple::buy m_num_apple 2 Apple::buy m_num_apple 3 m_num_apple 3, m_num_google 2 Apple::sell m_num_apple 2 Google::sell m_num_google 1 Google::sell m_num_google 0 Apple::sell m_num_apple 1 Apple::sell m_num_apple 0 m_num_apple 0, m_num_google 0
This article is contributed by Saket Kumar. If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.
- Design Patterns | Set 1 (Introduction)
- Design Patterns | Set 2 (Factory Method)
- Command Pattern
- Observer Pattern | Set 1 (Introduction)
- Observer Pattern | Set 2 (Implementation)
- Singleton Design Pattern | Implementation
- Decorator Pattern | Set 1 (Background)
- The Decorator Pattern | Set 2 (Introduction and Design)
- Decorator Pattern | Set 3 (Coding the Design)
- Strategy Pattern | Set 1 (Introduction)
- Strategy Pattern | Set 2 (Implementation)
- Adapter Pattern
- Iterator Pattern
- Curiously recurring template pattern (CRTP)
- Flyweight Design Pattern
Improved By : RamsTime