Re: Visitor Pattern Choices

Responding to Merlin...

Probably there is no right or wrong answer to this but I thought to ask
to put my mind at rest. Ok lets say you have a object hierarchy (eg.
the Glyph in Lexi from GOF book) and you want to use the visitor
pattern. So we place an accept method in the the base class glyph and
procede to create the visitor hierarchy. The accept signature will look
like this

void Glyph::Accept(Visitor& v);

The Visitor hierarchy will have a Vistor base class that will have a
visit method for each different type of Glyph so say if we have an
AssignnentNode and VariableNode there will be two methods

void visit(AssignnentNode& n);
void visit(VariableNode & n);

and in each concrete visitor we implement these methods to behave as we
wish. So far so good...

Imagine you think of 20 different types of operations that you like to
perform on your object structure and u like to use the Visitor pattern
to do this. So you create 20 different classes each implementing the
visitor interface.

Should we inherit all these 20 classes from our visitor base class? If
so this means a single Accept method in the object structure is
sufficent to serve all of these operations.

Should we create different and separate visitor hierarchies each with
its own accept method but grouping related operations together?

Should we go half way and create these groups but all inherit from a
common visitor base class. This approach also will require a single
accept method.

Currently I am leaning towards the last approach but I am worried that
having a single visitor hierarchy has tied 20 operations together (some
related while others unrelated). The hierarchy is more bushy and deeper
but it still

Whats the general feeling of the developer community on this topic?

Why do you "want" to use Visitor in the first place? Answer that question and you will answer the others.

IOW, which approach is best depends upon the nature of the collaborations in your particular situation. Thus if every flavor of Glyph needs to interact with the Visitor in a different way, you will need the first solution; if all flavors interact the same way, the second approach works; if Glyph flavors can be grouped by a few common interactions, then something in the middle will work.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: GOF Interface Problem
    ... >>Also, since it is a hierarchy of classes, with only the classes at the ... creating a rather messy hierachy. ... What does it mean to insert a glyph ... The OP has detected a point where the "word processor" sample application ...
    (comp.lang.cpp)
  • Re: GOF Interface Problem
    ... >>Also, since it is a hierarchy of classes, with only the classes at the ... creating a rather messy hierachy. ... What does it mean to insert a glyph ... The OP has detected a point where the "word processor" sample application ...
    (comp.object)
  • Re: Why ABCs make bad Interfaces
    ... Best idiomatic pratice with a C++ base class that is meant to serve as the ... Each derived class should declare the data members it requires. ... Many C++ coders are happily using ABC's as type class hierarchy interfaces. ...
    (comp.object)
  • Why cant static methods be overridden?
    ... Quite often I have a hierarchy of classes where ... I want a specific accessor method to be ... Therefore I specify ... it in the base class. ...
    (comp.lang.java.programmer)
  • Re: Generics + D2007/win32
    ... The source of ROSDK and DA alone probabily have 50 to 100 of those strongly ... need to retest stuff when you make changes at the bottom of the hierarchy. ... say you change the sorting alghoritm in the base class which ...
    (borland.public.delphi.non-technical)