VisitorPattern
COMP2511
Visitor Pattern
Prepared by
Dr. Ashesh Mahidadia
Design Patterns
Creational Patterns
v Factory Method
v Abstract Factory
v Builder
v Singleton
Structural Patterns
v Adapter
v Composite
v Decorator
COMP2511: Visitor Pattern 2
Behavioral Patterns
v Iterator
v Observer
v State
v Strategy
v Template
v Visitor
Visitor Pattern
Some of the material is from the websites https://refactoring.guru/design-patterns/ and the wikipedia pages.
3COMP2511: Visitor Pattern
Visitor Pattern
v Visitor is a behavioral design pattern that adds new operations/behaviors to the existing
objects, without modifying them.
v The visitor design pattern is a way of separating an algorithm from an object structure on
which it operates.
v A practical result of this separation is the ability to add new operations to existing object
structures without modifying the structures.
v It is one way to follow the open/closed principle.
v A visitor class is created that implements all of the appropriate specializations of the
virtual operation/method.
v The visitor takes the instance reference as input, and implements the goal (additional
behavior).
v Visitor pattern can be added to public APIs, allowing its clients to perform operations on
a class without having to modify the source.
COMP2511: Visitor Pattern 4
Visitor Pattern
Problem:
o A geographic information structured as one colossal graph.
o Each node of the graph may represent a city, an industry, a sightseeing area, etc.
o Each node type is represented by its own class, while each specific node is an object.
o Task: you want to export the graph into XML format.
COMP2511: Visitor Pattern 5
The XML export method had to be added into all node classes, which
bore the risk of breaking the whole application if any bugs slipped
through along with the change.
Visitor Pattern
Solution:
v The Visitor pattern suggests that you place the new behavior into a separate class called visitor,
instead of trying to integrate it into existing classes.
v The original object that had to perform the behavior is now passed to one of the visitor’s
methods as an argument, providing the method access to all necessary data contained within
the object (see the example for more clarification).
v The visitor class need to define a set of methods, one for each type.
For example, a city, a sightseeing place, an industry, etc.
v The visitor pattern uses a technique called “Double Dispatch” to execute a suitable method on a
given object (of different types).
o An object “accepts” a visitor and tells it what visiting method should be executed. See the
example for more clarifications.
o One additional method allows us to add further behaviors without further altering the code.
COMP2511: Visitor Pattern 6
Visitor Pattern: Structure
COMP2511: Visitor Pattern 7
The Visitor interface
declares a set of visiting
methods that can take
concrete elements of an
object structure as
arguments.
Each Concrete Visitor
implements several versions
of the same behaviors,
tailored for different
concrete element classes.
The Element interface declares
a method for “accepting”
visitors. This method should
have one parameter declared
with the type of the visitor
interface.
Each Concrete Elementmust
implement the acceptance
method. The purpose of this
method is to redirect the call to
the proper visitor’s method
corresponding to the current
element class. Be aware that
even if a base element class
implements this method, all
subclasses must still override
this method in their own classes
and call the appropriate method
on the visitor object.
The Client usually represents a collection or some
other complex object (for example,
a Composite tree).
1
2
3
4
5
Visitor Pattern: Example-1
COMP2511: Visitor Pattern 8
Visitor Pattern: Example-1
COMP2511: Visitor Pattern 9
Visitor Pattern: Example-2
COMP2511: Visitor Pattern 10
For more see: https://refactoring.guru/design-patterns/visitor/java/example
Visitor Pattern: Applicability and Limitation
Applicability:
Moving operations into visitor classes is beneficial when,
v many unrelated operations on an object structure are required,
v the classes that make up the object structure are known and not expected to change,
v new operations need to be added frequently,
v an algorithm involves several classes of the object structure, but it is desired to manage it in one
single location,
v an algorithm needs to work across several independent class hierarchies.
Limitation:
v extensions to the class hierarchy more difficult,
as a new class typically require a new visitmethod to be added to each visitor.
COMP2511: Visitor Pattern 11
End
COMP2511: Visitor Pattern 12