....and other creepy things from John Vlissides

The Visitor Pattern EXISTS! And its INTENT is to represent an operation to be performed on the elements of an object structure. And its INTENT is to represent an operation to be performed on the elements of an object structure.

How? By letting the user define a new operation without changing the classes of the elements on which it operates! By letting the user define a new operation without changing the classes of the elements on which it operates!

Motivation Consider a compiler with abstract syntax trees... Consider a compiler with abstract syntax trees...

Abstract Syntax Trees Compiler may need to define operations for: Type-Checking Code Optimization Flow Analysis Variable Checking...and more!

Meaning.... There will be one class for every single thing that needs to be performed... There will be one class for every single thing that needs to be performed... Distributing operations amongst various node classes is hard to understand, maintain and change! Distributing operations amongst various node classes is hard to understand, maintain and change! Adding a new operation would be a pain in the butt Adding a new operation would be a pain in the butt

What we want... Each new operation should be added separately Each new operation should be added separately All of the node classes to be independent of their operations All of the node classes to be independent of their operations

The Solution Package related operations from each class in a separate object, and pass it to elements of the abstract syntax tree as it is traversed. Package related operations from each class in a separate object, and pass it to elements of the abstract syntax tree as it is traversed. We call this object...

On a serious note When an element accepts a visitor, it sends a request to it that encodes the element’s class. When an element accepts a visitor, it sends a request to it that encodes the element’s class. It also includes the element as an argument. It also includes the element as an argument. The visitor is left to execute the operation for that element, which used to be in the class of the element. The visitor is left to execute the operation for that element, which used to be in the class of the element.

This is important too To make visitors work for more than just type-checking, we need an abstract parent NodeVisitor class for all visitors of an abstract syntax tree. To make visitors work for more than just type-checking, we need an abstract parent NodeVisitor class for all visitors of an abstract syntax tree.

NodeVisitor NodeVisitor must declare an operation for each node class. NodeVisitor must declare an operation for each node class.

Visitor – Up Close and Personal There are two class hierarchies with this pattern (page 332 – 333): There are two class hierarchies with this pattern (page 332 – 333): Node - for elements being operated on NodeVisitor - for the visitors that define operations on the elements

Visitor, continued A new operation is created by adding a new subclass in the visitors class hierarchy. A new operation is created by adding a new subclass in the visitors class hierarchy. New functionality can simply be added by defining new NodeVisitor subclasses. New functionality can simply be added by defining new NodeVisitor subclasses.

You know you wanna use this when... 1) An object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes. 2) Many distinct and unrelated operations need to be performed on objects in an object structure and you don’t want to “pollute” their classes with these operations. 3) The classes defining the object structure rarely change, but you often want to define new operations over the structure.

Participants Visitor – declares a visit operation for each class of ConcreteElement in the object structure Visitor – declares a visit operation for each class of ConcreteElement in the object structure ConcreteVisitor (PriceVisitor) – implements each operation declared by Visitor ConcreteVisitor (PriceVisitor) – implements each operation declared by Visitor Element (Trash) – defines an Accept operation that takes a visitor as an argument Element (Trash) – defines an Accept operation that takes a visitor as an argument

More Participants! ConcreteElement (Aluminum, Paper, Glass) – implements an Accept operation that takes a visitor as an argument ConcreteElement (Aluminum, Paper, Glass) – implements an Accept operation that takes a visitor as an argument ObjectStructure (next to Trash) ObjectStructure (next to Trash) - can enumerate its elements - can enumerate its elements - may provide a high-level interface to allow the visitor to visit its elements - may provide a high-level interface to allow the visitor to visit its elements - may be a composite or a collection like a set or list. - may be a composite or a collection like a set or list.

Collaborations A client that uses Visitor must create a ConcreteVisitor object and then traverse the object structure, visiting each element with the visitor (page 335) A client that uses Visitor must create a ConcreteVisitor object and then traverse the object structure, visiting each element with the visitor (page 335) When an element is visited, it calls the visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state, if necessary. When an element is visited, it calls the visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state, if necessary.

Consequences 1. Visitor makes adding new operations easy! 2. A Visitor gathers related operations and separates unrelated ones, simplifying classes defining elements and algorithms defined by visitors. 3. Adding new ConcreteElement classes is hard. 4. Visitor does not have access restrictions like an iterator does. It can visit objects that don’t have a common parent class, and you can add any type to a visitor interface. 5. Visitors can accumulate state as they visit each element in the object structure. 6. The Visitor pattern often forces you to provide public operations that access an element’s internal state, which may compromise encapsulation.

The Implementation I s on page 337.

Technical Details Double Dispatch – Visitor uses this to let us add operations to classes without changing them. Not all programming languages support it directly (like C++). Double Dispatch – Visitor uses this to let us add operations to classes without changing them. Not all programming languages support it directly (like C++). It means that operations get executed depending on the kind of request and types of two receivers, NOT one. It means that operations get executed depending on the kind of request and types of two receivers, NOT one.

This is Crucial! Because of double dispatch, an executed operation depends on the type of Visitor and the Element it visits. Because of double dispatch, an executed operation depends on the type of Visitor and the Element it visits. Binding operations can be done at run- time with “Accept” in lieu of statically with the element interface. Binding operations can be done at run- time with “Accept” in lieu of statically with the element interface.

And who is responsible...for object structure traversal?...for object structure traversal? After all, we know that a visitor must visit each element of the object structure.

Hmmm Responsibility can fall on: Responsibility can fall on: 1) the structure, 1) the structure, 2) the visitor, or 2) the visitor, or 3) a separate iterator 3) a separate iterator Most common is to use the structure itself, but an iterator is used just as effectively. Most common is to use the structure itself, but an iterator is used just as effectively. The visitor is used least often to do it, because traversal code often gets duplicated. The visitor is used least often to do it, because traversal code often gets duplicated.

Usage Visitor is not used often, at least according to and Visitor is not used often, at least according to and The Second site considers it totally useless. The Second site considers it totally useless. But don’t let that discourage you, because it’s a cool pattern. But don’t let that discourage you, because it’s a cool pattern.

And lastly... Visitor can be used to apply an operation over an object structure defined by the composite pattern. Visitor can be used to apply an operation over an object structure defined by the composite pattern. Visitor can also do the interpretation for the Interpreter pattern. Visitor can also do the interpretation for the Interpreter pattern.

Onto Vlissides!

Visiting Rights So far we’ve used Composite and Proxy for supporting symbolic links. So far we’ve used Composite and Proxy for supporting symbolic links. See Figure 2.3, page 29 See Figure 2.3, page 29 Composite contributed Node, File and Directory classes Composite contributed Node, File and Directory classes Proxy contributed the Link class. Proxy contributed the Link class.

Alexandrian Density The Node class is the Component in The Node class is the Component in the COMPOSITE pattern and the Subject in the PROXY pattern. Christopher Alexander (above) called Christopher Alexander (above) called this “density”. So he got the term named after him. So he got the term named after him. Lucky guy. Lucky guy.

Our File System The Node Interface is up for The Node Interface is up fordiscussion We want a minimal set of operations that lets clients build open-ended functionality. We want a minimal set of operations that lets clients build open-ended functionality. “Performing surgery” on the interface would be a hassle every time we wanted to add something new to it. “Performing surgery” on the interface would be a hassle every time we wanted to add something new to it.

Is there an alternative? What if we take functionality out of the node classes and put it into a client? What if we take functionality out of the node classes and put it into a client? We need Downcasts to do this, making the client complicated. We need Downcasts to do this, making the client complicated.

But Downcasts are yucky! Dynamic_cast (node) Dynamic_cast (node)

Visitor...TO THE RESCUE! Our file system problem is similar to the abstract syntax tree example Our file system problem is similar to the abstract syntax tree example By using the accept method like we did before, we let the visitor pattern do the work for us. By using the accept method like we did before, we let the visitor pattern do the work for us. Bottom line: No type tests or downcasting Bottom line: No type tests or downcasting

More on this Once we establish visiting rights by adding accept(Visitor &) to Node classes, those classes NEVER need to be modified again. Once we establish visiting rights by adding accept(Visitor &) to Node classes, those classes NEVER need to be modified again. Vlissides uses function overloading, but encoding the type of Node in the visit operation’s name works just as well (page 35-36) Vlissides uses function overloading, but encoding the type of Node in the visit operation’s name works just as well (page 35-36)

Is the Visitor right for you? The Visitor pattern isn’t The Visitor pattern isn’t for everyone. Consult for everyone. Consult your textbook to find out your textbook to find out if it’s the pattern that if it’s the pattern that you’re looking for. you’re looking for.

Things to Ask Yourself Is the class hierarchy I’m visiting stable? Or will it be changing like crazy? Is the class hierarchy I’m visiting stable? Or will it be changing like crazy? “Adding a new kind of Node may force us to change all the classes in the Visitor hierarchy just to add a corresponding visit operation.” Will the circular dependency between Visitor and Node class hierarchies bother you? Will the circular dependency between Visitor and Node class hierarchies bother you? A change to either base class interface is likely to prompt a recompile of both hierarchies.

Kevlin Henney: The guy who was referenced on Page 37 “C++ Overloading does not “C++ Overloading does not require having to overload all versions of visit or that you abandon overloading the visit member.”

Valuable Insight The “using” declaration allows us to inject names from a base class into a class for overloading. The “using” declaration allows us to inject names from a base class into a class for overloading. This maintains overloading regularity. This maintains overloading regularity. And it’s noninvasive because users are not forced to remember names or conventions from the visit function. And it’s noninvasive because users are not forced to remember names or conventions from the visit function.

Up Next: Security 1) Protecting the system from inadvertent and malicious corruption 1) Protecting the system from inadvertent and malicious corruption 2) Maintaining system integrity in the face of hardware and software errors. 2) Maintaining system integrity in the face of hardware and software errors.

Any Questions? Manne or Nick would love to answer them.

Credits The “Gang”: Erich Gamma Richard Helm Ralph Johnson John Vlissides References: Christopher Alexander Kevlin Henney Patterns Mentioned: VisitorCompositeProxyInterpreter Thanks For Watching: CSE 432 Inspiration Provided By: The Nick Yianilos Design Pattern Experience Good Teacher: Chris Gill Good TA’s: Chris Swope Yuling Liang