Visitor Pattern Choices

[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(V isitor& 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(Assignnen tNode& n);
void visit(VariableN ode & 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?

[Mateusz �oskot]

Gavin Deane wrote:

Mateusz Loskot wrote:

What I'm sure in 99% about is that having class with 100 member
functions is definitely not a good idea. Would you like to be a client
of such class? I would not ;-)

Ever used std::string? ;-)

Yup! I suppose you are pointing the problem considered by John Lakos in
his book about bloated interface of sample String class.

I can't count such big number of elements in std::string interface ;-)

Cheers
--
Mateusz �oskot
http://mateusz.loskot.net

[Gavin Deane]

Mateusz Loskot wrote:

Gavin Deane wrote:

Mateusz Loskot wrote:

What I'm sure in 99% about is that having class with 100 member
functions is definitely not a good idea. Would you like to be a client
of such class? I would not ;-)

Ever used std::string? ;-)

Yup! I suppose you are pointing the problem considered by John Lakos in
his book about bloated interface of sample String class.

I've not read Lakos's book, but I imagine he's making a similar point
to Herb Sutter here

http://www.gotw.ca/gotw/084.htm
I can't count such big number of elements in std::string interface ;-)

Including overloads, apparently it's 103.

Gavin Deane

[Mateusz �oskot]

Gavin Deane wrote:

Mateusz Loskot wrote:

Gavin Deane wrote:

Mateusz Loskot wrote:

What I'm sure in 99% about is that having class with 100 member
functions is definitely not a good idea. Would you like to be a client
of such class? I would not ;-)

Ever used std::string? ;-)

Yup! I suppose you are pointing the problem considered by John Lakos in
his book about bloated interface of sample String class.

I've not read Lakos's book, but I imagine he's making a similar point
to Herb Sutter here

http://www.gotw.ca/gotw/084.htm

Yup! That's very similar.

I can't count such big number of elements in std::string interface ;-)

Including overloads, apparently it's 103.

I don't count overloads. Indeed, from your point of
view std::string is a bog one.

Hm, I think I should drop it :-)))

Cheers
--
Mateusz �oskot
http://mateusz.loskot.net

[Mateusz �oskot]

Merlin wrote:

You will never be the client of a class with 100 member functions.
As Gavin Deane has pointed I'am -> std::string :-)
Talking about your problem, I'd say I don't know all your assumptions so
it's hard to guess.
You keep forgetting that the visitor base class will have as many
visit methods as there are nodes in the Glyph hierarchy, eg Row,
Column, Graphics, etc look in GOF.
I know that, but I also suppose that's not much of types.
In other words only a few methods will be in Visitor.
Yes.
BUT there will be 100 derived classes overriding these few methods in
different ways, each specific to the type of operation being carried
out.
Yes, but it's better solution with respect to extensibility and
future changes. IMHO, it's easier to add new subclass than to add new
member function.
When the time comes to use one these visitors, you only create an
OperationalVisi tor that you need and then apply it to your glyph.
Yup.

Now back to my original problem. 3 options exist

1) Have one visitorBase with 100 derived concrete visitors. One
accept method in Glyph
I vote for this one.
2) Have one visitorBase with the 100 concrete
visitors grouped in smaller hierarchies that derive from visitorBase.
One accept method in Glyph
This is a kind of variation of 1) solution. Depending on project
assumptions I'd use this too.
3) Have a family of visitors each with
its own baseclass and a corresponding accept method in glyph(ie
multiple accept methods)
As I said, I feel it's not a good idea :-)

The common interface exists for all 100 visitors. It consists of the
visit methods for the various different types of nodes for the glyph
hierarchy.

I'd say, it consists of specialized (x 100) implementations of visit
member function but the interface is common.

Cheers
--
Mateusz �oskot
http://mateusz.loskot.net

[Merlin]

Hi Murali
How would u go about using templates in such a circumstance. Can u give
an example. Make one up if mine is not any good for ur purposes. I am
curious in what you have said.

Thanks

[Murali Krishna]

Merlin wrote:

Hi Murali
How would u go about using templates in such a circumstance. Can u give
an example. Make one up if mine is not any good for ur purposes. I am
curious in what you have said.

Thanks

Hi Merlin,

I dont have GOF. B'coz of that I could not Understand your Question.
visit this page: http://home.earthlink.net/~huston2/dp/VisitorDemosCpp
an example starts with "// Purpose. Visitor design pattern"

Visitor class is like this..

class Visitor { public:
virtual void visit( This* e ) = 0;
virtual void visit( That* e ) = 0;
virtual void visit( TheOther* e ) = 0;
};

One of Visitor Child class is like this..

class UpVisitor : public Visitor {
/*virtual*/ void visit( This* e ) {
cout << "do Up on " + e->thiss() << '\n'; }
/*virtual*/ void visit( That* e ) {
cout << "do Up on " + e->that() << '\n'; }
/*virtual*/ void visit( TheOther* e ) {
cout << "do Up on " + e->theOther() << '\n'; }
};

and some other classes...

// 1. Add an accept(Visitor) method to the "element" hierarchy
class Element { public:
virtual void accept( class Visitor& v ) = 0;
};

class This : public Element { public:
/*virtual*/ void accept( Visitor& v );
string thiss() { return "This"; }
};

Similarly That class, TheOther classes are defined in the same way.
accept method is overridden so we cannot use templates on that.

/*virtual*/ void This::accept( Visitor& v ) { v.visit( this ); }
/*virtual*/ void That::accept( Visitor& v ) { v.visit( this ); }
/*virtual*/ void TheOther::accep t( Visitor& v ) { v.visit( this ); }

Class hierarchy is this..

Element <- This, That, TheOther
Visitor <- UpVisitor, DownVisitor

but.. visit method is overloaded in UpVisitor & DownVisitor. we can use
templates on that.
Instead of e->thiss(), e->That(), e->TheOTher() calls used in Visit
method, if we create a common method in all classes (This, That &
TheOther), say getName() we can use templates. Other wise there is no
other way. If the Visit method has to behave differently for different
parameters, you have to overload one by one.

Plz let me know if this is near to your Question.

Wish You all Happy New Year,
Murali Krishna.

[Murali Krishna]

Merlin,

I worked on this after giving the above example.
I am able to use templates but this solution has a problem. I think
templatizing will not work.
The problem is..
The Elements derived classes also uses Visitor Objects in accept fn. So
we have to use templates. which means we have to define a templatized
method for every type and UpVisitor objects have to be declared for
every type.
ex:- UpVisitor<This> upThis; UpVisitor<That> upThat;
UpVisitor<TheOt her> upTheOther;

which completely deviates the main Idea and requirement.
I think my solution is not correct or I am not able to use templates
porperly.

---
Murali Krishna.

[Merlin]

Thanks Murali for trying. I am unlikely to use templates as my visitors
are unlikely to be used on any other structure than the one I am
designing it for. I was just curious to see how you would go about
doing this.

Happy New Year to you too!