Visitor | Cheat Sheet
Behavioral Pattern — Design Patterns Series
Visitor is a behavioral design pattern that lets you separate algorithms from objects they operate on.
Real-life examples
- Paying for goods in the supermarket: Some products are immediately scanned with the price, others must be weighed first to determine the price
- Offering different and customised insurances by a representative at the home/customer visit — in the shop: theft insurance; in the sawmill: fire insurance
Meaning
- Representation of an operation to be applied to elements of an object structure
- Definition of new operations without changing the class of the elements it processes
Applicability (suitable if …)
- An object structure contains many classes of objects with different interfaces and object operations that depend on the concrete classes
- Many individual and diverse operations can be performed with objects of an object structure
- Operations are defined in the same class
- Changes to the classes within the object structure occur infrequently, but new operations need to be set up for them frequently
- Changes to classes require a redefinition of all Visitor interfaces (then operations should be defined in the class)
Assets and Drawbacks
- Visitor objects facilitate the addition of new operations
- Unites similar operations and separates dissimilar ones from each other (location in the Visitor object)
- Adding new concrete classes is difficult because each element leads to a new abstract Visitor operation
- Use of the pattern depends on the frequency of changes to the classes
- Cross-class hierarchy visits (subclass, superclass)
- Leads to the collection of states
- Violation of encapsulation and thus violation of Open-Closed-Principle
Example
In the following example you can sort the varieties of a fruit box and determine the number of each fruit.
As a prerequisite, we need mock data of Fruits and the corresponding interface:
The fruit class reflects the Element of the Visitor Pattern. It defines an Accept() operation that takes a Visitor object as an argument:
Oranges, Apples, and others demonstrate the concrete implementation of the interface:
The Visitor declares a visit() operation for each concrete Element class (here fruit class) in the object structure. The class that sends the visit request to the Visit object, which is identified by the name and signature of the operation:
The concrete class of the Visitor implements the concrete operations of the Visitor interface. Each operation implements one of the steps of the algorithm defined for the associated class of objects:
Finally, you instantiate your mock data and the concrete Visitor class. After that, you can partition your fruits:
Conclusion
Design Patterns are an important resource and base knowledge for every developer — they are very helpful for solving programmatic problems, help with consistent communication with other developers about system design, and serve as a significant introduction into object composition (besides inheritance) and dependency inversion.
Behavioral Patterns deal with algorithms and assignment of responsibilities to objects. Furthermore, they describe mutual communication patterns and grasp complex program sequences. They are therefore very well suited for use in areas where complicated code needs to be made readable and maintainable. Extensions are, in consequence, very good and quickly implementable.
Follow me on Medium, or Twitter, or subscribe here on Medium to read more about DevOps, Agile & Development Principles, Angular and other useful stuff. Happy Coding! :)
