Re: When and where to use Visitor Pattern?

On 29 Apr 2005 02:47:04 -0700, Nicholls.Mark@xxxxxxxxx wrote:

>>>There doesn't seem to be a fundumental difference here.
>
>>There is a huge difference in the execution timeline. There is also a
>
>>big difference in the dependency structure.
>
>There does seem to be a difference in execution time and dependendency.
>
>The visitor (to me) exhibits the more coupling of the options, because
>it forces any usage to be coupled to all visititable types, while "if
>(instanceof(xyz))" only depends on those explicitly stated......this
>may or may not be necessary....in general the safest way is to assume
>that making a decision based on the type/interface of a object is
>intrinsically linked to all possibilities....visitor enforces
>this.....the "if (instanceof(xyz))"....doesn't.

I agree that the standard visitor is strongly coupled. Each visitor
derivative depends on each derivative of the context class. If new
derivatives are added, all the visitors must be rebuilt and redeployed
along with all the context derivatives.

On the other hand, if you use an if/else chain of instanceof, then the
class(es) that contain that chain must be modified for every new
derivative of the context.

On the other hand, the if/else chain has a runtime complexity of O(n),
whereas the visitor has a runtime complexity of O(1). Granted the
'n' is small, but the cost can still be high.

The acyclic visitor solves the dependency problem of visitor while
compromising little to its speed. Acyclic Visitor also gives the
ability to decouple individual visitors from the context derivatives
in a manner similar to the if/else chain.

In short, the acyclic visitor combines all the best attributes of each
approach with the exception that it is nowhere near as easy to
understand as the if/else chain.

So the trade-off become one of clarity over coupling. I suggest that
the visitor patterns are well enough known that the clarity issue is
strongly mitigated. If one sees the name XYZVisitor, one has a big
clue as to what is going on.

In the end there is a place for all three approaches. if/else chains
are best used when the number of derivatives are very small, the
number of repeated chains are very small, and the hierarchy is not
likely to grow. Visitor is best used when the number of derivatives
is not likely to grow, but the number of visitors is. And acyclic
visitor is best used when both the number of derivatives and the
number of visitors are likely to grow.

>To me the omision of a dependency that does exist is as bad (if not
>worse) that the inclusion of one that doesn't. i.e. if coupling is
>inherent it should exist in the code.

I don't follow this. It is not possible to omit a dependency that
actually exists. It *is* possible to move dependencies to less
vulnerable parts of the code. The three variations that we are
talking about are simply different configurations of the existing
dependencies.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.

Relevant Pages

  • Re: When and where to use Visitor Pattern?
    ... >along with all the context derivatives. ... You have removed the dependency yes.....but you have changed the ... >On the other hand, if you use an if/else chain of instanceof, then the ... the coupling and the recompilation....(I'm assuming we ...
    (comp.object)
  • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
    ... >>to hold spinlocks in the mutexes as the dependency tree is atomically ... >>unpredictable order of mutexes traversed. ... If the dependency chain is ... As an implementation note, single-owner hard spinlocks seem ...
    (Linux-Kernel)
  • [RFC/PATCH PATCH 3/6] lockdep: Annotate Read/write states
    ... Currently we do not save the recursive read dependencies in the dependency ... since we never have the chain 1 in our dependency list. ... This helps us to define the conflicting states for each lock with ease: ... * Allow read-after-read recursion of the same ...
    (Linux-Kernel)
  • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
    ... >>the hardirq threads, ... solution is to hold spinlocks in the mutexes as the dependency ... traversal of the chain where contention within the chain under ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)