COMP 310
Fall 2015

Lec19:  Visitors...

Home  Info  Owlspace   Java Resources  Eclipse Resources  Piazza

Let's continue our discussion of visitors from last lecture.

The Visitor Design Pattern is used for type-dependent processing.

Important points to remember:

Here is a nice write-up about the visitor pattern by a former Comp410 student, Nav Ravindranath (Fall 2014), who rediscovered the visitor pattern when he got to industry:    Note how coming to understand design is an iterative process of continually re-evaluating one's own work and thoughts.


Consider the following Visitor Design Pattern implementation:


 Run the on-line Visitor demo.

Also, see the List Framework (listFW) visitor demo.

Important Visitor Design Pattern Features

A host calls its corresponding case on the visitor -- That's the only thing the host knows how to do.  It's case is the only case it is aware of.   In some sense, this behavior defines the host.

A host executes a visitors without semantic -- the host has no idea what a visitor does.

A visitor simply provides  the services of its cases -- A visitor does not know when or how it will be used.

Hosts provide intrinsic, atomic behaviors for the visitors to use -- The hosts must provide the host-dependent behaviors that cannot be done by anyone else.

Visitors create algorithms by combining the atomic, intrinsic behaviors of their hosts -- Visitors are fundamentally external to the hosts and thus visitor behavior can only be based on the public methods offered by the hosts.

The hosts and the visitor are mutually dependent on each other -- a host needs a visitor to execute its algorithms and a visitor needs a host to provide its intrinsic behaviors.

The number of hosts is invariant -- The number of host classes is tied to the number of cases the visitor provides because there is a one-to-one relationship between the two.   This is a critical design decision.

The number of visitors is variant - A finite number of hosts can support an arbitrary number of visitors.

Visitors do NOT depend on the inter-relations between hosts -- It is a common myth that visitors are tied to recursion and composite data structures.    Visitors are usable on any abstract host hiearchy where distinguishable hosts are identifiable.

To run a visitor-based processing of a host, neither the visitor nor the host concrete types needs to be known -- The visitor system runs at the top interface levels so it decouples from the specifics of which type of host is currently present and which type of visitor is currently being used.   Arbitrary processing of arbitrary data.


The "Sweet Spot" for Visitors

Visitors are the most effective in situations where multiple or changeable algorithms (processing) need to be run on objects at a point in the system where the type of the objects is not known but yet the algorithm depends on the object's type.

This is a surprisingly common situation in highly abstract systems.



Additional Lecture Materials  (All Required!)


Using a Visitor to Process Two Unknown Hosts


Visitor Exercises:     Required, though do not turn in.   Complete BEFORE attempting homework!

  1. Extend the on-line Visitor demo:
    1. Write at least 2 more visitors that have distinctly different outputs for each host.
    2. Add at least one text field that allows an input parameter to be passed to the visitor when it is executed.  Write at least 2 visitors that show both host-dependent and input parameter-dependent behavior.
  2. Extend the List Framework (listFW) visitor demo:
    1. Write the following algorithms in each of the following manners: as a reverse accumulation-style visitor, as a forward accumulation-style visitor, as an accumulator with FoldRAlgo and as an accumulator with FoldLAlgo:
      1. Return the largest value in a list of integers.   (Might be useful in some implementations: Integer.MIN_VALUE is the smallest possible Java integer value)
      2. Return a boolean indicating whether or not a given element is in the list.
    2. Write the following algorithms in each of the following manners: as a forward accumulation-style visitor and as an accumulator with FoldLAlgo:
      1. Return the last element of the list (why can't you do this with reverse accumulation?)
    3. Write the following algorithms in any style you wish, maybe even a combination of styles:
      1. Sum the elements in a list of integers from the n'th element to the end of the list.
      2. Return a list with the smallest element from the list removed.   Do this with a single pass through the the list!

You are absolutely encouraged to attempt more algorithms!  The more practice you get in writing visitor algorithms, the better off you will be for the rest of the semester!

© 2015 by Stephen Wong