Re: Visitor pattern, code generation and additional sub classes

On 22 Feb., 19:14, Daniel Pitts
<newsgroup.spamfil...@xxxxxxxxxxxxxxxxxxx> wrote:
Lothar Behrens wrote:
Hi,

I have implemented the visitor pattern to achive a simple way to save
and load my data.

My current problem I am thinking of is the following issue:

I have a visitor for my application (interface lb_I_Application), but
this is a base class / interface.
An implementation derives from it. So then there would be multible
implementations I cannot handle
with one Accept class.

I think either I'm misunderstanding you, or you misunderstand the
visitor pattern.

With the Visitor pattern, you have some structure of things, possibly
heterogeneous.  You have an interface that defines what happens when a
particular type of node in that structure is reached.

interface FooVisitor {
    void visitFoo(Foo foo);
    void visitBar(Bar bar);
    void visitEndOfFile();

}

Then, you have a FooBarContainer, which abstract the actual structure.
For every object in the structure, it calls the appropriate visit*
method in the passed in container.

You might also use a Double Dispatch pattern, where Foo and Bar will
call the appropriate method themselves, if the type isn't known at
compile-time.



I am using the Double Dispatch pattern, thus I have several visit(...)
methods, but not for the
base class of my object tree structure, thus it fails to compile when
I add new classes.

Sample:

class lb_I_Aspect : public lb_I_Unknown
{ // abstract interface for visitors
public:

// The lb_I_Streamable interface would possibly go impossible
//virtual void LB_STDCALL visit(lb_I_Unknown*) { printf("Error: Catch
all visitor called!\n"); }
virtual void LB_STDCALL visit(lb_I_Boolean*) = 0;
virtual void LB_STDCALL visit(lb_I_String*) = 0;
virtual void LB_STDCALL visit(lb_I_XMLDocument*) = 0;

// New types must be declared here as visit method's and implemented
in all my visitor implementations ...

};

class lb_I_FileOperation :
public lb_I_Aspect
{
protected:
lb_I_FileOperation() {}
virtual ~lb_I_FileOperation() {}

public:
virtual bool LB_STDCALL begin(char* file) = 0;
virtual bool LB_STDCALL begin(lb_I_Stream* stream) = 0;
virtual void LB_STDCALL end() = 0;
virtual lb_I_Stream* LB_STDCALL getStream() = 0;
};

// A visitor that saves the XML document of some types.
class XMLSaveVisitor : public lb_I_FileOperation {
public:

void LB_STDCALL visit(lb_I_Boolean*);
void LB_STDCALL visit(lb_I_String*);
void LB_STDCALL visit(lb_I_XMLDocument*);

bool LB_STDCALL begin(char* file);
bool LB_STDCALL begin(lb_I_Stream* stream);
void LB_STDCALL end();
lb_I_Stream* LB_STDCALL getStream();
}:

I think I have to use the catch all variant as described in Modern C++
Design from Andrei Alexandrescu.
(ISBN: 0-201-70431-5)

I have done that by a subclass for a 'generic' application class. But
this class or interface has no subclass,
thus I simply have to delegate the operation (visit) to a class having
a method to be called and passed the
lb_I_Stream instance.

But this is a delegation of a specific class to a special companion
class knowing the internas of the application
and thus knows how to save. (I always have a pair of application and
the companion class for that application)

What I mean is adding new basic types like lb_I_Foo or lb_I_Bar, that
hasen't been declared above.
If I create a plugin that would be downloaded later than the program
version I have released, I haven't
any way to modify existing visitor implementations to add these new
methods.

A good sample is a diagramming application a customer has and I have
developed basic shapes. Then the customer
buys a plugin with shapes I never have seen or have the code. That way
the visitor without catchall is not possible.

I search how the catchall could be implemented to look for further
visitor implementations. All available visitors could be
iterated (iterator pattern) and the visit call could be delegated to
these visitors until one doesn't fail in to a catchall.

I have found a paper that may handle this topic and it is very
interesting. It may using these techniques :-)

http://www.eknowlogie.com/Papers/VisitorSC/

Regards

Lothar
.

Relevant Pages