[xsd-users] Visitor pattern automatically generated/ and/or included

[Christopher Fuhrman]

Hello,

On Mon, Jul 20, 2009 at 11:19 PM, Boris Kolpackov
<boris at codesynthesis.com>wrote:

> Say you have schema a.xsd which defines type A and schema b.xsd which
> defines type B. The resulting visitor class for this object model would
> look like this:
>
> struct Visitor
> {
>  virtual void visit (A&) = 0;
>  virtual void visit (B&) = 0;
> };
>
> Because when the XSD compiler is running on a.xsd it doesn't know
> anything about b.xsd (and vice versa), it is not clear when and
> how the above interface could be generated.
>

One of the assumptions about the applicability of the Visitor design pattern
is that the data structure is not likely to change. The third point in the
"Applicability" section of
http://www.oodesign.com/visitor-pattern.html(which is similar to the
original GoF reference for Visitor):

The object structure is not likely to be changed but is very probable to
> have new operations which have to be added. Since the pattern separates the
> visitor (representing operations, algorithms, behaviors) from the object
> structure it's very easy to add new visitors as long as the structure
> remains unchanged.


Automatically generated object structures seem *very* likely to change. I
don't think the traditional Visitor makes sense for that reason.

The original question mentions getting an automatically generated traverser,
which is similar to two variants of Visitor mentioned in GoF: traversing
logic in an Iterator or in the Composite structure. It might make sense in a
code-generation scenario to generate this traversing logic, but without
using a Visitor that knows about all elements. Maybe it would make sense to
hand-code a Visitor in this case once (if?) the data structure is stable?

-- 
Christopher Fuhrman
Professor
Department of Software and IT Engineering
École de technologie supérieure (ETS)
http://profs.logti.etsmtl.ca/cfuhrman/
+1 514 396 8638