Below are various signs that developers successfully use
traversals and visitors in their work. Several of them refer to the Visitor
pattern from GOF (Gamma et al. book on Design Patterns).
The Visitor pattern allows you to name and reuse traversals and
to specify the visitors.
The Visitor pattern and its many variants has the disadvantage
that the programs don't adapt to changes in the inheritance and part-of
hierarchies. Only the AP approach with succinct traversal
specifications provides increased flexibility.
(for further discussion, see the SIGSOFT '96 paper:
Here is a table highlighting the benefits of AP with respect
to the Visitor Pattern:
without AP with AP
add an accidental class change each visitor visitor unchanged
change traversal code no change to traversal spec.
add an essential class change each visitor change some visitors
change traversal code small change to traversal spec.
traversal not structure-shy structure-shy
visitors not selective selective
If programmed directly in Java or C++, visitors and traversals can
be implemented in many different ways. Some possibilities are:
1. GOF Visitor pattern implementation: Requires a visitor method
for each class in the traversed class graph. Allows to reuse
same traversal several times with different visitor classes which
are all subclasses of the same visitor class.
2. Demeter/C++ approach described in the AP book.
3. Demeter/Java approach.
4. Approaches described in the literature below.
John Vlissides has addressed the
Visitor pattern in his Pattern Hatching column
in the C++ report (SIGS Publications). The two relevant articles are:
1. The Trouble with Observer: September 1996
2. Visiting Rights: September 1995
The PLOP '96 conference contains several
From email@example.com Fri Jun 28 15:23:03 1996
From: Ron Lusk
Subject: RE: when are manager (mediator) patterns appropriate?
Date: Fri, 28 Jun 1996 14:46:18 -0400
> It sounds to me like the GOF Visitor pattern might be
> useful in building some (clearly not all) of the "Manager"
> objects that need to manipulate the database.
I just ended my work on a project where the database-flavored objects
were in a Composite, and were coupled enough to the application that
Composite objects would detect events in their containers and respond
appropriately. The responses, however, were embodied in Visitors which
would traverse the appropriate levels of the Composite and update the
database/check constraints/determine data completeness/etc.
At the beginning of the project, my lead developer was saying, "I don't
know why we need all these Visitor things; it just makes things
complicated." By the end, I'd overhear him telling our project leader
(my client), "Sure, we can do that; I'll just fire off a Visitor when
[some event] occurs, and the Visitor will implement that policy. I'll
have it for you this afternoon."
BTW, *my* design goal for the project was to use all the GOF patterns; I
missed that goal by four patterns, so I hope to get called back for
release 2. ;^)