[jdom-interest] Design Patterns

[Frank Sauer]

Correct. accept() is the correct term.
Using reflection is just one possible implementation
of the Visitor interface, one that would eliminate the
need for the Visitable interface, but you lose the
strong typing of the double dispatching.

Frank Sauer
The Technical Resource Connection, Inc.
a wholly owned subsidiary of Perot Systems
Tampa, FL
http://www.trcinc.com
-----------------------------------------------
Java: The best argument for Smalltalk since C++


-----Original Message-----
From: Richard Cook [mailto:rpc at prismtechnologies.com]
Sent: Wednesday, May 02, 2001 2:31 PM
To: Frank Sauer; jdom-interest at jdom.org
Subject: RE: [jdom-interest] Design Patterns


I think the method in Visitable is normally called accept() ?

Alternatively, I think you can use reflection to implement a visitor type
thing (sorry, haven't checked this so I'm probably making a fundamental
mistake):

public class VisitorImpl {
   public void visit(Object obj) {
      try {
         java.lang.reflect.Method m =
            getClass().getMethod("visitImpl", new Class[] {
obj.getClass()});
         m.invoke(this, new Object[] { obj });
      }
      catch (NoSuchMethodException e) {
         // default processing
      }
      catch (...)
      }
   }

   public void visitImpl(Element e) { }
   public void visitImpl(Attribute a) { }
}

If we had a Node interface you could have visit(Node) to make it a bit more
restrictive (and more likely you would have something you don't already know
the concrete class), there's a bit of a "bad smell" about it though!


> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Frank Sauer
> Sent: Wednesday, May 02, 2001 6:36 PM
> To: 'jdom-interest at jdom.org'
> Subject: RE: [jdom-interest] Design Patterns
>
>
> Here's some more thoughts on this:
>
> The Visitable interface could look like:
>
> interface Visitable {
> 	public Object visit(Visitor aVisitor);
> }
>
> and the implementation in most cases will look like:
>
> public Object visit(Visitor aVisitor) {
> 	return aVisitor.visit(this);
> }
>
> Alternatively, the Visitor could have methods like:
>
> 	visitElement(Element anElement)
> 	visitDocument(Document aDoc)
>
> etc.
>
> Alternative implementations of visit can then look like (in Element for
> example):
>
> public Object visit(Visitor aVisitor) {
> 	aVisitor.visitElement(this);
> }
>
> and Document can implement it as :
>
> public Object visit(Visitor aVisitor) {
> 	aVisitor.visitDocument(this);
> }
>
> ALL the behavior is in the actual implementation of the
> Visitor interface. For example, an OutputVisitor, JTreeBuilderVisitor,
> etc. I;ve done some pretty complicated tree stuff using this pattern,
> and once you get the hang of it, it's easy. You have to get used to the
> one-line implementations of visit and the double dispatching.
>
> Frank Sauer
> The Technical Resource Connection, Inc.
> a wholly owned subsidiary of Perot Systems
> Tampa, FL
> http://www.trcinc.com
> -----------------------------------------------
> Java: The best argument for Smalltalk since C++
>
>
> Frank Sauer
> The Technical Resource Connection, Inc.
> a wholly owned subsidiary of Perot Systems
> Tampa, FL
> http://www.trcinc.com
> -----------------------------------------------
> Java: The best argument for Smalltalk since C++
>
>
> -----Original Message-----
> From: Frank Sauer [mailto:Frank.Sauer at trcinc.com]
> Sent: Wednesday, May 02, 2001 1:15 PM
> To: 'jdom-interest at jdom.org'
> Subject: RE: [jdom-interest] Design Patterns
>
>
> I think you're mistaken there. All that the visitor
> pattern requires is that all objects being visited
> implement some kind of Visitable interface accepting
> a Visitor (interface) in some kind of a visit method.
> This does not require a common base class and each class
> being visited can have completely different implementations
> of the visit method. Personally I think a Visitor pattern
> could be the answer to the tree walking issues in relation to
> this common Node discussion.
>
> Frank Sauer
> The Technical Resource Connection, Inc.
> a wholly owned subsidiary of Perot Systems
> Tampa, FL
> http://www.trcinc.com
> -----------------------------------------------
> Java: The best argument for Smalltalk since C++
>
>
> -----Original Message-----
> From: Trimmer, Todd [mailto:todd.trimmer at trizetto.com]
> Sent: Wednesday, May 02, 2001 12:05 PM
> To: 'jdom-interest at jdom.org'
> Subject: [jdom-interest] Design Patterns
>
>
> More than one request to add functionality has been responded with "Use a
> Decorator for this" or "Use a Visitor for that."
>
> Both of these patterns assume a base class for a hierarchy of
> objects to be
> acted upon. Does anyone realize how much harder these patterns are to
> implement without an underlying interface? Wouldn't Node solve
> this problem?
>
>
>
> Todd Trimmer
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com