Connecting Tech Pros Worldwide Forums | Help | Site Map

Visitor Pattern Choices

Merlin
Guest
 
Posts: n/a
#1: Dec 29 '05
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
Guest
 
Posts: n/a
#2: Dec 29 '05

re: Visitor Pattern Choices


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
Guest
 
Posts: n/a
#3: Dec 29 '05

re: Visitor Pattern Choices


Murali Krishna wrote:[color=blue]
> I did not completly understand what you said.
> I am not able to understand the class hierarchy.[/color]

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


Jonathan

Mateusz Łoskot
Guest
 
Posts: n/a
#4: Dec 29 '05

re: Visitor Pattern Choices


Merlin wrote:[color=blue]
> 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?
>[/color]

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
--
Mateusz Łoskot
http://mateusz.loskot.net
Murali Krishna
Guest
 
Posts: n/a
#5: Dec 29 '05

re: Visitor Pattern Choices


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
Guest
 
Posts: n/a
#6: Dec 29 '05

re: Visitor Pattern Choices


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@hotmail.com
Guest
 
Posts: n/a
#7: Dec 29 '05

re: Visitor Pattern Choices


Murali Krishna wrote:[color=blue]
> 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?[/color]

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

Mateusz Łoskot
Guest
 
Posts: n/a
#8: Dec 29 '05

re: Visitor Pattern Choices


Merlin wrote:[color=blue]
> Firstly thank you for your replies guys but I think maybe you are
> unfamiliar with the visitor pattern.[/color]

I'm pretty familiar with Visitor but may be you don't give us clear
picture of the problem. I think both are possible :-)
[color=blue]
> Let me rephrase my question.[/color]

OK, let's try again.
[color=blue]
> 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.[/color]

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
--
Mateusz Łoskot
http://mateusz.loskot.net
Gavin Deane
Guest
 
Posts: n/a
#9: Dec 29 '05

re: Visitor Pattern Choices



Mateusz Loskot wrote:[color=blue]
> 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 ;-)[/color]

Ever used std::string? ;-)

Gavin Deane

Mateusz Łoskot
Guest
 
Posts: n/a
#10: Dec 29 '05

re: Visitor Pattern Choices


Gavin Deane wrote:[color=blue]
> Mateusz Loskot wrote:
>[color=green]
>>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 ;-)[/color]
>
>
> Ever used std::string? ;-)[/color]

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
Merlin
Guest
 
Posts: n/a
#11: Dec 29 '05

re: Visitor Pattern Choices


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
Guest
 
Posts: n/a
#12: Dec 29 '05

re: Visitor Pattern Choices



Mateusz Loskot wrote:[color=blue]
> Gavin Deane wrote:[color=green]
> > Mateusz Loskot wrote:
> >[color=darkred]
> >>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 ;-)[/color]
> >
> >
> > Ever used std::string? ;-)[/color]
>
> Yup! I suppose you are pointing the problem considered by John Lakos in
> his book about bloated interface of sample String class.[/color]

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
[color=blue]
> I can't count such big number of elements in std::string interface ;-)[/color]

Including overloads, apparently it's 103.

Gavin Deane

Mateusz Łoskot
Guest
 
Posts: n/a
#13: Dec 29 '05

re: Visitor Pattern Choices


Gavin Deane wrote:[color=blue]
> Mateusz Loskot wrote:[color=green]
>>Gavin Deane wrote:[color=darkred]
>>>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? ;-)[/color]
>>
>>Yup! I suppose you are pointing the problem considered by John Lakos in
>>his book about bloated interface of sample String class.[/color]
>
> 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[/color]

Yup! That's very similar.
[color=blue][color=green]
>>I can't count such big number of elements in std::string interface ;-)[/color]
>
> Including overloads, apparently it's 103.[/color]

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
Guest
 
Posts: n/a
#14: Dec 29 '05

re: Visitor Pattern Choices


Merlin wrote:[color=blue]
> You will never be the client of a class with 100 member functions.[/color]

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.
[color=blue]
> 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.[/color]

I know that, but I also suppose that's not much of types.
[color=blue]
> In other words only a few methods will be in Visitor.[/color]

Yes.
[color=blue]
> BUT there will be 100 derived classes overriding these few methods in
> different ways, each specific to the type of operation being carried
> out.[/color]

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.
[color=blue]
> When the time comes to use one these visitors, you only create an
> OperationalVisitor that you need and then apply it to your glyph.[/color]

Yup.
[color=blue]
>
> Now back to my original problem. 3 options exist
>
> 1) Have one visitorBase with 100 derived concrete visitors. One
> accept method in Glyph[/color]

I vote for this one.
[color=blue]
> 2) Have one visitorBase with the 100 concrete
> visitors grouped in smaller hierarchies that derive from visitorBase.
> One accept method in Glyph[/color]

This is a kind of variation of 1) solution. Depending on project
assumptions I'd use this too.
[color=blue]
> 3) Have a family of visitors each with
> its own baseclass and a corresponding accept method in glyph(ie
> multiple accept methods)[/color]

As I said, I feel it's not a good idea :-)
[color=blue]
>
> 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.
>[/color]

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
Guest
 
Posts: n/a
#15: Dec 29 '05

re: Visitor Pattern Choices


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
Guest
 
Posts: n/a
#16: Dec 31 '05

re: Visitor Pattern Choices



Merlin wrote:
[color=blue]
> 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[/color]

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
Guest
 
Posts: n/a
#17: Dec 31 '05

re: Visitor Pattern Choices


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.

---
Murali Krishna.

Merlin
Guest
 
Posts: n/a
#18: Jan 2 '06

re: Visitor Pattern Choices


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!

Closed Thread