visitor : Java Glossary


Visitor is a design pattern. Typically you write a Visitor class with visit methods that take as a parameter each of the various types of nodes. You then hand this class to the accept method of the Tree, which then enumerates the nodes of the tree, calling your appropriate visit method for each node.

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 could clone your code and insert that logic into the tree spanning code. Let’s say instead you did it with the visitor pattern.

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:

where visitFile can do whatever it wants to this node. The boolean says whether to quit. You might further add methods similar to FilenameFilter’s to filter out files and directories you don’t want to visit.

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.

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number