1 Motivation Consider a compiler that represents programs as - - PDF document

1

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1

Podcast Ch08-12

♦Title: Visitor Design Pattern ♦Description: Motivation; an example;

class structure; implementation issues

♦Participants: Barry Kurtz (instructor);

Brandon Winters, Sara Hyde, Cheng Vue, Dan Baehr (students)

♦Textbook: Object-Oriented Software

Engineering: Using UML, Patterns and Java by Bernd Bruegge and Allen H. Dutoit

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

A Pattern Taxonomy

Pattern Structural Pattern Behavioral Pattern Creational Pattern

Composite Decorator Adapter Bridge Façade Proxy Iterator Visitor Command Observer Template Strategy Singleton Abstract Factory Builder Factory Prototype

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

the basics

♦ ♦ Intent

Intent: Represent an operation to be performed on the elements of an object structure.

♦ Visitor lets you define a new operation without

changing the classes of the elements on which it

• perates

♦ ♦ aka

aka: none!

These slides were borrowed from lecture notes on Design Patterns by Brian Malloy at Clemson University

2

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

Motivation

♦ Consider a compiler that represents programs as

Abstract Syntax Trees (ASTs)

♦ need to perform operations on ASTs

type checking code generation printing

♦ One option: place all of these operations in the nodes

• f the AST

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5

Node class hierarchy

Node typeCheck() generateCode(); prettyPrint(); VariableRefNode typeCheck() generateCode(); prettyPrint(); AssignmentNode typeCheck() generateCode(); prettyPrint();

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

Problem with Node class hierarchy

♦ Distributing operations across Node classes leads to a

system that’s hard to understand, maintain and change.

♦ it’s confusing to have type-checking code in the same

class with code to perform pretty printing.

♦ also, adding a new operation, e.g. data flow analysis,

requires recompiling all of the classes!

3

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7

Visitor

♦ allows us to separate Node classes from operations

“on” Node classes

♦ allows each new operation to be added separately,

without changing Node class!

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8

Nodes “accept” visitors

Node accept(NodeVisitor) VariableRefNode accept(NodeVisitor) AssignmentNode accept(NodeVisitor v) program v.visitAssignment(this)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

Visitor for Nodes

NodeVisitor

visitAssignment(node); visitVariableRef(node);

VariableRefNode

visitAssignment(node); visitVariableRef(node);

AssignmentNode

visitAssignment(node) visitVariableRef(node)

4

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10

Visitor Pattern

♦ Define two

two class hierarchies

• ne for elements being operated on (nodes)
• ne for visitors that define operations on the elements

♦ create new operations by adding a new subclass to

Visitor class hierarchy

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

Structure

• f Visitor

Pattern

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

Collaborations

5

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

Circularity

♦ inherent in Visitor pattern: Visitor needs elements

& elements need Visitor

♦ emanates from double dispatch ♦ In Java, it’s much easier, don’t have to worry about

forward references, or quick compiles

♦ C++ strives for efficiency, at a cost in programmer

expertise

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

Single Dispatching

♦ Two criteria determine the operation:

name of the request type of the receiver Example: calling node->generateCode() on an assignment Node will dynamically bind to the generateCode() function in AssignmentNode

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

Double Dispatch

♦ operation that gets executed depends on

kind of request types of two receivers example: accept() is double dispatched operation. Its meaning depends on two types: Visitor’s and Element’s

6

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

More implementation issues

♦ A visitor must visit each element of the structure ♦ Who is responsible for traversing the structure?

• bject structure -- most often

an iterator the visitor -- problem: you will likely dupe traversal code in each concrete visitor

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

Accumulating State

♦ Visitors can accumulate state as they traverse ♦ without a visitor, this state information might have to

be passed during traversal

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

Consequences

♦ Easy to add new operations ♦ Visitor gathers related operations and separates

unrelated operations

♦ Adding new ConcreteElement classes takes extra

work -- need new abstract operation on Visitor