VISITOR DESIGN PATTERN

1
VISITOR DESIGN PATTERN

• Sara Khan
• Albert Wong

2
What is it?

• Hmm.
• am still thinking.!!
• well.
• can you help?

3
Consider

• Considering NATORounds and WARSAWRounds class
  both implement the Rounds interface.

Rounds
NATORounds
WARSAWRounds
4
TASK 1

• NATO print list from 1-n.
• WARSAW print list in reverse order

5
Solution

• Trivially, we would just add a print() in both
  NATO and WARSAW classes separately.
• Each print method will implement a different
  functionality, based on requirements.
• Simple and a very intuitive solution.

6
TASK 2

• Add the reverse list printing functionality in
  both classes.
• Also, dont eliminate the previous print().
• The implementation should be flexible enough, to
  allow the user to pick either one.

7
Solution

• Add two separate print() print(),
  reversePrint() in both classes separately.
• PROBLEM
• Requires making modification to all classes
  implementing the interface.
• What if you were had 50 classes to modify?
• What if you wanted more than 2 implementations?
  How many separate methods are required?
• Any other?

8
EFFICIENT SOLUTION

• Packaging related operations from each class in a
  new interface/subclass.
• This allows more flexibility, as modifications to
  the algorithm can be made at any point.
• Luckily, we have a design pattern to solve that!

9
PATTERN

• Visitor lets you define a new operation without
  changing the classes of the elements on which it
  operates.
• In other words, a particular object can be
  assigned different implementation without having
  to modify its class.
• Visitor design pattern is another interpretation
  of the Composite Design pattern

10

• Instead of adding operations to structures, allow
  structures to be visited.
• Allows independent definition of visitors (ie
  everyone can independently define visitors, add
  them later etc.).

11
Participants

• Visitor (RoundVisitor)
• Declares a Visit operation for each class of
  ConcreteElement.
• Visitor identifies the class that sent the Visit
  request, by the operations name and signature.
• Visitor then can access the element directly
  through its particular interface.
• ConcreteVisitor (PrintVisitor PrintVisitor2)
• Implements each operation declared by Visitor.
• Each operation implements an algorithm for
  defined class.
• Provides the context for the algorithm and stores
  its local state.
• Element (Round)
• Defines an Accept operation that takes a visitor
  as an argument.

12

• ConcreteElement (NATORound WASAWRound)
• Implements an Accept operation that takes a
  visitor as an argument.
• ObjectStructure (Program)
• May provide a high-level interface to allow the
  visitor to visit its elements.
• May either be a Composite lt gt or a collection
  such as a list or set.

13
(No Transcript)
14
Sequence
15
Advantages

• Adding new operations is easy
• Related behavior isn't spread over the classes
  defining the object structure it's localized in
  a visitor.
• Unrelated sets of behavior are partitioned in
  their own visitor subclasses.

16
Disadvantages

• Adding new ConcreteElement classes is hard. Each
  new ConcreteElement gives rise to a new abstract
  operation on Visitor and a corresponding
  implementation in every ConcreteVisitor class.
• The ConcreteElement interface must be powerful
  enough to let visitors do their job. You may be
  forced to provide public operations that access
  an element's internal state, which may compromise
  its encapsulation.

17
Single vs. Double dispatch

• Double-Dispatch
• The actual method invoked depends on the name of
  the request and the types of two receivers
• For example, consider an object of type Visitor1
  calling accept(Visitor1) on an object of Type
  ElementA
• The Visitor1 object dispatches a call to the
  accept(Visitor) method of ElementA
• The accept(Visitor) method of ElementA dispatches
  a call back to the visitor (Visitor1), invoking
  the visit(ElementA) method of Visitor1 and
  passing itself as an argument.
• This round trip effectively picks up the right
  type of Element, ensuring that the correct
  visit() method of the Visitor object is called

18

• Single-Dispatch
• The actual method invoked depends on the name of
  the request (method signature) and the type of
  the receiver object
• For example, calling foo() on a object of Type X,
  invokes the foo() method of X
• The actual underlying type will be discovered
  through polymorphism
• This is the standard technique used in languages
  like Java and C

19
(No Transcript)