visitor : Java Glossary

Here is an example. Let’s say you wrote code to enumerate all the directories and files in a directory tree on disk.

Let’s say you wanted then to:

1. find files older than 1 year
2. find files whose root name is the same as the directory

You encapsulate your logic in a Visitor object you present to each node in a directory tree on disk. In might have a two methods:

• boolean visitDir ( File dir)
• boolean visitFile ( File dir, String file )

The enumerating womb might provide service methods for the Visitors, e.g. delete and extract.

With this structure, you don’t need to meddle with your tree spanning code every time you invent a new Visitor. Further, you can use your Visitor code on anything else that is a collection of dirs and files, e.g. a flat file list, a database… Your Visitors work unmodified. Because you have separated out the logic of spanning the collection from the logic of processing a member, you can you mix and match, plugging them together any way you want.

The problem in designing a Visitor is deciding just how much information to present to the Visitor. If you present too much, you limit the contexts is which your Visitors can be used. If you present too much, you waste time collecting information the Visitor never uses. If you present too little, you won’t be able to handle future problems with the impoverished Visitor interface. You can ameliorate this problem by creating layered Visitor interfaces and then using only as many of the layers as you need to in your Visitor and implementing as many as you can on a given collection.

As you add Visitors, you may well discover you want to refactor your code and change the interface to more smoothly accommodate all the various problems you want to solve with Visitors. It is easier to refactor early.

Unfortunately, I have not encountered a standard set of battle-hardened Visitor interfaces to use.

The alternative way of looking at the problem is to write specialised Iterators for all your collections. A one-shot Visitor become a loop body or a methods called as a loop body. The Visitor pattern can be more selective. It does not need to visit every element in a collection.

A generalisation of the visitor pattern is useful for processing sorted lists where there are duplicate keys. The framework also calls a custom a startGroup method at the start of a group of duplicates. Then it calls a custom endGroup afer processing the group of duplicates.

A further generalisation of that is the control break, where you have several levels of sorted key. The framework invokes custom start and end methods specific to each level when there is a change at each level. When a major key changes it counts as minor levels changing too, even when they are indentical between reconds.