The Visitor Design Pattern
EECS3311: Software Design Fall 2017
CHEN-WEI WANG
Open/Closed Principle
Software entities (classes, features, etc.) should be open for , but closed for modification .
extension
⇒ When the behaviour of a system, we may add new code, but we should not modify the existing code.
e.g., In the design for structures of expressions:
3 of 12
extending
○ Closed: Syntactic constructs of the language [stable] ○ Open: New operations on the language [unstable]
Motivating Problem (1)
Based on the you learned, design classes to model of arithmetic expressions
(e.g., 341, 2, 341 + 2).
composite pattern
structures
2 of 12
Motivating Problem (2)
Extend the composite pattern to support operations such as evaluate, pretty printing (print prefix, print postfix), and type check.
4 of 12
Problems of Extended Composite Pattern
● Distributing the various unrelated operations across nodes of the abstract syntax tree violates the single-choice principle :
To add/delete/modify an operation
⇒ Change of all descendants of EXPRESSION
● Each node class lacks in cohesion :
A class is supposed to group relevant concepts in a single place. ⇒ Confusing to mix codes for evaluation, pretty printing, and type checking.
⇒ We want to avoid “polluting” the classes with these various unrelated operations.
5 of 12
Visitor Pattern
Visitor Pattern: Architecture
● Separation of concerns :
○ Set of language constructs
7 of 12
Visitor Pattern Implementation: Structures
Cluster expression language
○ Declare deferred feature accept(v: VISITOR) in EXPRSSION. ○ Implement accept feature in each of the descendant classes.
class CONSTANT …
accept(v: VISITOR) do
v.visit_ constant (Current) end
end
class ADDITION …
accept(v: VISITOR) do
v.visit_ addition (Current) end
end
6 of 12
8 of 12
[closed, stable] [open, unstable] ⇒ Classes from these two sets are decoupled and organized into
○ Set of operations
two separate clusters.
Visitor Pattern Implementation: Operations
Cluster expression operations
○ For each descendant class C of EXPRESSION, declare a deferred
feature in the deferred class VISITOR.
○ Each descendant of VISITOR denotes a kind of operation.
class EVALUATOR
: INTEGER
visit_constant(c: CONSTANT) do := c.value end visit_addition(a: ADDITION)
local eval_left, eval_right: EVALUATOR do a.left.accept(eval_left)
a.right.accept(eval_right)
:= eval_left.value + eval_right.value
end 9 of 12 end
visit_c (e: C)
class VISITOR
visit_constant(c: CONSTANT) deferred end visit_addition(a: ADDITION) deferred end
end
value
value
value
To Use or Not to Use the Visitor Pattern
● In the architecture of visitor pattern, what kind of extensions is easy and hard? Language structure? Language Operation?
○ Adding a new kind of operation element is easy.
To introduce a new operation for generating C code, we only need to introduce a new descendant class of VISITOR, then implement how to handle each language element in that class. ⇒ Single Choice Principle is obeyed.
○ Adding a new kind of structure element is hard.
After adding a descendant class MULTIPLICATION of EXPRESSION, every concrete visitor (i.e., descendant of VISITOR) must be amended to provide a new operation.
visit multiplication
⇒ is violated.
● The applicability of the visitor pattern depends on to what
extent the structure will change.
⇒ Use visitor if operations applied to structure might change.
⇒ Do not use visitor if the structure might change. 11 of 12
C CODE GENERATOR
Single Choice Principle
Testing the Visitor Pattern
1 2 3 4 5 6 7 8 9
10 11
test_expression_evaluation: BOOLEAN
local add, c1, c2: EXPRESSION ; v: VISITOR do
create {CONSTANT} c1.make (1) ; create {CONSTANT} c2.make (2) create {ADDITION} add.make (c1, c2)
create {EVALUATOR} v.make
add.accept(v)
check attached {EVALUATOR} v as eval then Result := eval.value = 3
end end
Double Dispatch in Line 7:
1. DT of add is ADDITION ⇒ Call accept in ADDITION
2. DT of v is EVALUATOR ⇒ Call visit addition in EVALUATOR
visitingresultofadd.left +
v.visit
addition
(add)
10 of 12
visiting result of add.right
Index (1)
Motivating Problem (1)
Open/Closed Principle
Motivating Problem (2)
Problems of Extended Composite Pattern Visitor Pattern
Visitor Pattern: Architecture
Visitor Pattern Implementation: Structures Visitor Pattern Implementation: Operations Testing the Visitor Pattern
To Use or Not to Use the Visitor Pattern
12 of 12