[jdom-interest] Design Patterns

[Richard Cook]

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