Visitor Pattern Intent Represent an operation to be performed on all of the components of an object structure Define new operations on a structure without changing the classes representing the components

Visitor – Motivation Representing composite computer equipment Operations spread out OO style but ... difficult to add a new operation describe * price * FLOPPY_DISK + COMPOSITE_EQUIPMENT + .... describe + price + describe + price +

Visitor Architecture – Equipment Example Equipment classes are independent of the operations Equipment accept visitors and direct them to the appropriate operation – through polymorphism * EQUIPMENT_VISITOR accept * EQUIPMENT + PRICING_VISITOR + CHASSIS accept visit_chassis One subclass of EQUIPMENT_VISITOR for each operation One subclass of EQUIPMENT for each concrete piece of equipment

Visitor – Applicability Object structure contains many classes of objects with differing interfaces and want to perform operations that depend on their concrete classes Many distinct and unrelated operations need to be performed Do not want to or are unable to clutter the concrete classes with these operations Keep the related operations together, e.g. operations on pricing various types of EQUIPMENT are all in the PRICING_VISITOR class If the object structure is shared by many applications, Visitor puts operations into only those applications that need them

Visitor – Applicability – 2 The classes defining the object structure rarely change, but you often want to define new operations over the structure Changing object structure means redefining interface to all visitors, which is costly If object structure changes often, Visitor is inappropriate

Visitor – Abstract Architecture ELEMENT * visit_elem_A ( ELEM_A ) * visit_elem_B ( ELEM_B ) * ... accept ( VISITOR ) * ... ELEM_A + CONCRETE_VISITOR_1 + accept ( VISITOR ) + ... visit_elem_A ( ELEM_A ) + visit_elem_B ( ELEM_B ) + ... ELEM_B + CONCRETE_VISITOR_2 +

Visitor – Participants Element Declares accept method that takes a visitor as an argument Concrete element Implements the accept method Visitor Declares a visit operation for each concrete element class

Visitor – Participants – 2 Concrete visitor Implements every visit operation declared in Visitor Each visit operation implements a fragment of the algorithm defined for the concrete visitor Provides the context for the algorithm composed of all of the visit fragments State accumulates with each visit Implements the high level organization Iteration over the components Processing each in turn

Visitor – Scenario A pricing visitor visits a composite equipment For each equipment, the pricing visitor selects which method from the EQUIPMENT_VISITOR interface to execute Scenario: Visit a cabinet 1 Accept the pricing visitor 2 visit_cabinet 3 visit_children 4 Accept the pricing visitor MAIN 1 2 PRICING_VISITOR CABINET 3 4 CHASSIS

Visitor – Consequences Adding new operations is easy New operation implements the Visitor interface, e.g. the methods in EQUIPMENT_VISITOR All the fragments of the visitor algorithm are in one file – related behaviours are together Easier to make sure that elements are working in unison Unrelated operations and fragments are in other visitor classes Contrast with having to change each of the concrete element classes to have the operation fragment Each class has a fragment of each of the operations

Visitor – Consequences – 2 Adding new concrete elements is difficult Need to modify the Visitor interface Need to modify each concrete visitor Can sometimes simplify as many elements have common behaviour (default behaviour) that can be specified at concrete visitor level 1. Create subclasses of level 1 for more specific behaviour for the new elements Only program the new elements For many structures elements do not change rapidly so this is not a problem

Visitor – Consequences – 3 One can visit object structures composed of unrelated objects The various visit_* methods do not have to take arguments that are related The main difference between Visitor and Iterator State accumulation Visitors contain data structures related to the operation they implement, e.g. the PRICING_VISITOR contains the total price Without a visitor, such data would have to be passed as arguments (or become global variables)

Visitor – Related Patterns Visitor pattern is used to apply an operation over a Composite