3.3 Visitor design pattern  (Page 4/5)

3. the visitor pattern

The visitor pattern is a pattern for communication and collaboration between two union patterns: a "host" union and a "visitor" union.  An abstract visitor is usually defined as an interface in Java.  It has a separate method for each of the concrete variant of the host union.  The abstract host has a method (called the "hook") to "accept" a visitor and leaves it up to each of its concrete variants to call the appropriate visitor method.  This "decoupling" of the host's structural behaviors from the extrinsic algorithms on the host permits the addition of infinitely many external algorithms without changing any of the host union code.  This extensibility only works if the taxonomy of the host union is stable and does not change.  If we have to modify the host union, then we will have to modify ALL visitors as well!

NOTE: All the "state-less" visitors, that is visitors that contain no non-static fields should be singletons.  Visitors that contain non-static fields should not be singletons.

4.  fundamental object-oriented design methodology (foodm)

1. Identify and separate the variant and the invariant behaviors.
2. Encapsulate the invariant behaviors into a system of classes.
3. Add "hooks" to this class to define communication protocols with other classes.
4. Encapsulate the variant behaviors into a union of classes that comply with the above protocols.

The result is a flexible system of co-operating objects that is not only reusable and extensible, but also easy to understand and maintain.

Let us illustrate the above process by applying it to the design of the immutable list structure and its algorithms.

1. Here, the invariant is the intrinsic and primitive behavior of the list structure, IList , and the variants are the multitude of extrinsic and non-primitive algorithms that manipulate it, IListAlgo .
2. The recursive list structure is implemented using the composite design pattern and encapsulated with a minimal and complete set of primitive structural operations:  getFirst() and getRest() . 
3. The hook method Object execute(IListAlgo ago,  Object inp) defines the protocols for operating on the list structure. The hook works as if a IList announces to the outside world the following protocol: If you want me to execute your algorithm, encapsulate it into an object of type IListAlgo, hand it to me together with its inp object as parameters for my execute(). I will send your algorithm object the appropriate message for it to perform its task, and return you the result.
   • emptyCase(...) should be the part of the algorithm that deals with the case where I am empty.
   • nonEmptyCase(...) should be the part of the algorithm that deals with the case where I am not empty.”
4. IListAlgo and all of its concrete implementations forms a union of algorithms classes that can be sent to the list structure for execution.

Below is the UML class diagram of the resulting list design.  Click here to see the full documentation.   Click here to see the code .

The above design is nothing but a special case of the Visitor Pattern .  The interface IList is called the host and its method execute() is called a " hook " to the IListAlgo visitors .  Via polymorphism, IList knows exactly what method to call on the specific IListAlgo visitor.  This design turns the list structure into a (miniature) framework where control is inverted: one hands an algorithm to the structure to be executed instead of handing a structure to an algorithm to perform a computation. Since an IListAlgo only interacts with the list on which it operates via the list’s public interface, the list structure is capable of carrying out any conforming algorithm, past, present, or future. This is how reusability and extensibility is achieved.