Visitor Pattern Problem

[Roshan Lal]

Thanks Ija. That was very helpful.
[ January 22, 2003: Message edited by: Roshan Lal ]

[Ilja Preuss]

Originally posted by Roshan Lal:
[QB]I read that thru Visitor Pattern additional operations can be added to an existing class structure without touching the existing structure.
How is it possible? Does not the class structure has to have an equivalent of "accept" method preinstalled taking an Abstract Visitor as argument? Usually when we create class structures, we don't put such a method for future use.

Yes, for installing the first Visitor, you probably have to add an accept method. But after that, you can add as many Visitors as you like without touching the class ever again.

Also, the return type of such "accept" method will have to be known in advance.

Typically, the return type of accept is void. Instead of returning a value, it will do a "side effect" on the Visitor object to achieve something similar.

So basically how can we acheive adding new operations without modifying exsiting class structure (what if we don't have the source code of that class structure on which we want to add operations)?

That's hard to impossible in a language like Java.

I am not find Visitor very useful in practice. Is it me or is Visitor only useful in very limited situations?

I don't use it very often - but still sometimes it seems to be the best thing to do to me...

[Frank Carver]

This seems a little baffling. Did Roshan Lal delete or empty the original question ? Or is this somehow a reply to another thread ?

[Roshan Lal]

Yes, It's my mistake. I used edit/delete instead of reply with quote. I am sorry.
-Roshan

Originally posted by Frank Carver:
This seems a little baffling. Did Roshan Lal delete or empty the original question ? Or is this somehow a reply to another thread ?

[Alex Garrett]

Visitor is actually a pretty powerful pattern for reducing the coupling between systems. For example, imagine that you're designing an application for generating reports with graphics. The requirement is that you should be able to generate any sort of shape for graphs, include text, and export the whole thing as a PDF.
At an abstract level, you'll be dealing with things like rectangles, lines, textboxes, fonts, strokes and fills. However, when the time comes to render it as a PDF you need to have your arbitrary shapes emit "PDF stuff".
Really, you have two systems here. One for manipulating shapes and one for generating a PDF document. Rather than tightly coupling your shapes to the PDF description language, it's better to have a PDFVistor that goes to each object and interrogates it to put together a PDF document. Here's some fake code:

public class Page implements Visitable {
private List drawables;
private int orientation = PORTRAIT;
public static final int PORTRAIT = 1;
public static final int LANDSCAPE = 2;


public void addDrawable(Drawable _d) {
this.drawables.add(_d);
}

public void setOrientation(int _orientation) {
this.orientation = _orientation;
}

public int getOrientation() {
return this.orientation;
}

public Collection getDrawables() {
return this.drawables;
}

public void accept(Visitor _v) {
_v.accept(this);
}
}
public class Rectangle implements Visitable, Drawable {
private double xCoord;
private double yCoord;
private double length;
private double height;

// getters & setters

public void accept(Visitor _v) {
_v.accept(this);
}
}
public class PDFVisitor implements Visitor {
private Stack stack;
public void accept(Page _page) {
PDFDocument pdfDoc = (PDFDocument)stack.peek();
PDFPage pdfPage = new PDFPage();
pdfPage.setOrientation(Page.getOrientation()); // assumes orientation is same
pdfDoc.addPage(pdfPage);
stack.push(pdfPage);
Iterator i = _page.getDrawables().iterator();
while (i.hasNext()) {
Drawable d = (Drawable)i.next();
d.accept(this);
}
stack.pop(); // get rid of old page -- pdfDoc still has reference
}
public void accept(Rectangle _r) {
PDFPage pdfPage = (PDFPage)stack.peek();
PDFRectangle pdfRect = new PDFRectangle(_r); // let the PDF rect interrogate
pdfPage.addRectangle(pdfRect);
}
}

Obviously, it's not real code -- there's no error checking, or anything like that. Also, it shows the process somewhere in the middle -- I assume there's a Document and a PDFDocument that have already been visited. You would probably want to have a grammar for your shapes and one for the PDF generator, to ensure that the transformation proceeds according to spec. But this should provide a general idea.
Also, "Uncle Bob" wrote a good article on Visitor that you can find at http://www.objectmentor.com/resources/articles/visitor
Cheers, Alex
[ January 22, 2003: Message edited by: Alex Garrett ]

[Roshan Lal]

Alex, thanks for explaining. Yeah, I agree that Visitor can be very useful. The confusion I had comes from statement like this "Visitor allows the operation to be added 'without modifying the existing class structure'".
Yes, the new operations are not added in the existing structure but the structure has to be modified to install the "accept" method. So for example, if we have a stable class structure and do not have source code (say it is from a thirdparty), then we cannot install the "accept" method and hence we cannot use Visitor. From your example, suppose we had taken shapes classes from some third-party and then we want to use PDF generator, then how do we use Visitor because there won't be an "accept" method pre-installed for us.
I am more on the line of thinking as Ilja said, it is perhaps impossible to use Visitor in Java if we do not have source code for the base class structure.
I hope I am making myself clear.
Thanks again
Roshan

[Alex Garrett]

That's true, but you can get around it a bit by using the Adapter pattern. For example:

public class VisitableRectangle implements Visitable {
private ClosedRectangle rectangle;

public double getWidth() {
return rectangle.getWidth();
}

// other accessors are similarly delegated to ClosedRectangle

public void accept(Visitor _v) {
_v.accept(this);
}
}
public class PDFVisitor {
public void visit(VisitableRectangle _rect) {
PDFRectangle pdfRect = new PDFRectangle();
pdfRect.setWidth(_rect.getWidth()); // getWidth delegated to ClosedRectangle
}
}

We just wrap up the closed class, delegating all calls to it, except for the accept. Remember, the only thing the accept method does is give the Visitor a handle for automatic delegation (i.e., delegating by method overloading, rather than if-then statements.)
Alex

Originally posted by Roshan Lal:
Alex, thanks for explaining. Yeah, I agree that Visitor can be very useful. The confusion I had comes from statement like this "Visitor allows the operation to be added 'without modifying the existing class structure'".
Yes, the new operations are not added in the existing structure but the structure has to be modified to install the "accept" method. So for example, if we have a stable class structure and do not have source code (say it is from a thirdparty), then we cannot install the "accept" method and hence we cannot use Visitor. From your example, suppose we had taken shapes classes from some third-party and then we want to use PDF generator, then how do we use Visitor because there won't be an "accept" method pre-installed for us.
I am more on the line of thinking as Ilja said, it is perhaps impossible to use Visitor in Java if we do not have source code for the base class structure.
I hope I am making myself clear.
Thanks again
Roshan

[Roshan Lal]

Alex, actually you are right. The work-around you give would work. Thanks for your insight.
-Roshan