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(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?

 

[Murali Krishna]

I did not completly understand what you said.
I am not able to understand the class hierarchy.

but I am able to understand that you want to overload the visit
function 20 times. That is not really needed and it is very painful.

Use templates instead of that.

If you know templates, you will understand need for reusability,
especially when you want to overlaod several hundred times. You will
create only one function and you use it for any kind of datatype
(including user-defined)

 

[Jonathan Mcdougall]

I did not completly understand what you said.
I am not able to understand the class hierarchy.

Please quote the message you are answering to and do read about the
visitor pattern.


Jonathan

 

[Guest]

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?

I'm not sure what is the problem here and what you are asking about.
If I understand it correctly, you try to have different visitors
implementing different algorithms. Am I right?

If I am, then I'd try to combine Visitor pattern with Strategy pattern.
I'm not sure about possible redundancy here so may be someone else
would like to comment it.

In other words, if you have GoF in front of you take a look at the
Strategy (page 315) and there are two classes in sample: Composition and
Compositor. My idea is to make Composition a Visitor whish uses
different strategies. Does it make sens to anybody? I'm curious too
Cheers

 

[Murali Krishna]

Hi Jonathan,

Thanks for that. Any way I am new to this Google group. I wanted to
Quote. Frankly, I dont know how to do that. Help me how to quote. Next
time I'll start quoting.
Any way did my answer gave any solution?

 

[Merlin]

Firstly thank you for your replies guys but I think maybe you are
unfamiliar with the visitor pattern.
Let me rephrase my question.
Is it a good idea to have just a single Accept method in the Glyph
class for all the visitor classes even if there are 100's? Or should we
group these
visitors logically and introduce different Accept methods in the Glyph
class. I dont see whats not clear about this question... maybe I need
some sleep!

Regards

 

[deane_gavin]

Hi Jonathan,

Thanks for that. Any way I am new to this Google group. I wanted to
Quote. Frankly, I dont know how to do that. Help me how to quote. Next
time I'll start quoting.
Any way did my answer gave any solution?

It's not a Google group, it's a Usenet group. Google groups is just one
of the ways of reading and posting.

Instead of clicking Google's "Reply" link at the bottom of the message,
click "Show Options" at the top of the message then use the "Reply"
link revealed there. You will find the message you are replying to is
automatically quoted for you. Remember to post your message below or
inline with what you are replying to (but not above) and to snip
unnecessary context.

I posted this message from Google Groups and quoted you without a
problem.

Gavin Deane

 

[Guest]

Firstly thank you for your replies guys but I think maybe you are
unfamiliar with the visitor pattern.

I'm pretty familiar with Visitor but may be you don't give us clear
picture of the problem. I think both are possible

Let me rephrase my question.

OK, let's try again.

Is it a good idea to have just a single Accept method in the Glyph
class for all the visitor classes even if there are 100's? Or should
we group these visitors logically and introduce different Accept
methods in the Glyph class.

Hard to say because I don't know your structure much.
So, I'll ask additional question.

Can all those Visitors be unified in terms of common interface?
May be you can solve your problem by inheritance from common Visitor
interface. Then all Visitors would be used in unified way (common
interfaace) but they could still distinguish in terms of implementation.
In such case you need only one Accept function which takes Visitor by
it's interface (pointer to Visitor base class).

Please, not I said "may be", so try to fit my idea (if you like) to your
problem becasue you know it (the problem) best.

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 ;-)

Cheers

 

[Gavin Deane]

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? ;-)

Gavin Deane

 

[Guest]

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

 

[Merlin]

Hi Mateusz

You will never be the client of a class with 100 member functions. 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. In other words only a few methods will be in
Visitor. BUT there will be 100 derived classes overriding these few
methods in different ways, each specific to the type of operation being
carried out.

When the time comes to use one these visitors, you only create an
OperationalVisitor that you need and then apply it to your glyph.

Now back to my original problem. 3 options exist

1) Have one visitorBase with 100 derived concrete visitors. One accept
method in Glyph
2) Have one visitorBase with the 100 concrete visitors grouped in
smaller hierarchies that derive from visitorBase. One accept method in
Glyph
3) Have a family of visitors each with its own baseclass and a
corresponding accept method in glyph(ie multiple accept methods)

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.


Thanks

 

[Gavin Deane]

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

 

[Guest]

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.

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

 

[Guest]

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
OperationalVisitor 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

 

[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]

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::accept( 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<TheOther> 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.

 

[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!