, a variation of VisitorPattern
Documented in PatternLanguagesOfProgramDesign
volume three (1997), chapter 7.
Available online as http://www.objectmentor.com/publications/acv.pdf
It is discussed and developed in ModernCeePlusPlusDesign
"The Acyclic Visitor
pattern allows new functions to be added to existing class hierarchies without affecting those hierarchies, and without creating the dependency cycles that are inherent to the GangOfFour VisitorPattern
[...quoted with light editing.]
The receiver of the Visitor dynamic_casts the Visitor to determine
if it is the type of Visitor it will accept, and if so, passes itself to
How is this better than:
An operation or class that will only operate on a specific subtype
dynamic_casts the instance to determine if it is of that subtype.
The Visitor pattern has two purposes:
1) Enumeration -> as target of an iteration through a collection of a known set of subtypes
2) Type Determination (CapabilityQuery?
) -> determine which subtype we are currently examining.
If there is no need for an enumeration target, and a dynamic_cast is acceptable
for the Capability Query, there is no need for the Visitor Pattern.
Does anybody want to comment on this observation? Does it make sense?
I developed AcyclicVisitor
independently in designing class frameworks. (JohnVlissides
also developed a variation in VisitorInFrameworks
In a particular UserInterface
framework, a state machine (StatePattern
) controlled the software's progress through a dialogue with the user. When the user acts, this can cause an event (CommandPattern
) to be sent to the state machine, causing it to change to the next state in the dialogue. But what events might a state receive? And how might it handle these events? Answer: It depends on the application. But I can't recompile the framework every time someone wants to create a custom event in a new application. That's that nasty cyclic dependency.
So I pushed the issue of event-handling onto the application. For each event class the application defined, it needed a corresponding event receiver class. If a particular state needed to respond to a particular kind of event, the state class would inherit from the appropriate receiver. The event would then DynamicCast
to the corresponding receiver class, executing the event if the cast was successful.
In another instance, I was creating a diagnostic framework. Diagnostic tests inherited from a test base class (StrategyPattern
). Each class of test would generate test-specific status, which could be relayed to the user. But the application needs to be able to use application-specific test classes, with application-specific status classes. And the diagnostic framework needs to be completely decoupled from the UI, which may even have its own completely separate framework.
So for each status class, there is a corresponding status receiver class. Each status class knows what kind of receiver can grok it, and DynamicCast
s to it. One status message, one DynamicCast
. At least it's better than a list of twenty DynamicCast
s in a gigantic if-then-elseif, as the UI code hunts around for a kind of status it knows about.
I recently refactored my way into a situation identical to that Tim describes (quite a testament to the magic of
refactoring): State + Command compelled Visitor, and then I had a peloton of cycles to get rid of.
It turns out that AcyclicVisitor
as written, translated into JavaLanguage
, still has a cycle between each element-
Visitor pair. Element subclasses (commands) refer to each Visitor subclass (state) via an interface; each
Visitor interface must refer to an element subclass, and we have a cycle. The cycle doesn't affect the framework,
but I don't like to tolerate even little local ones.The cycle can be easily removed by having
Visitors refer to elements via interfaces, but I had a large number of elements, they were quite simple,
and the code bloat of having an interface for each element seemed excessive.
Looking for better solutions I came across UncleBob
's Java version,
which has the same issue, perhaps indicated by the bidirectional arrows in the diagram, although not explicitly
discussed. (I believe the issue almost goes away in CeePlusPlus
if the elements and Visitors see each others' declarations
but not their definitions, but I haven't worked through it.)
I settled for using reflection, more or less as described in
. This completely removes any knowledge of the whole
business from the elements. The reflective dispatch can be done in one place in a Visitor superclass. The result
is quite economical and easy to follow. The only hitch is that because the visit methods are only called via
reflection, code checkers think they're unused.
CategoryPattern CategoryJava CategoryCpp