perlperl
asked on
use of visitor data pattern
I have been reading a lot last few days about visitor data pattern but my head just can't digest it ;) on how to use it in my application. I came across a situation in my application code, where I think I might be able to make it more robust and efficient and visitor pattern came to mind. However I wasn't sure if I can apply it or not. I don't want use it just for the heck of using it ;)
Here's my existing design:
Now I need to extend my application to add 4 more derived classes from Acc
class Acc_Der_9 : public Acc;
class Acc_Der_10 : public Acc;
class Acc_Der_11 : public Acc;
class Acc_Der_12 : public Acc;
Each of them will have their own implementation of common_method(Arg1, arg2);
This will also force me to update the factory class to add 4 more condition check to return the correct derived class object.
Based on this requirement, is it feasible to use "Visitor Design Pattern". If so what are the pros and cons of it.
Here's my existing design:
1) Virtual Base class with one pure virtual function:
class Acc {
virtual uint32_t common_method(uint32_t arg1, uint32_t arg2) = 0;
};
2) There are 8 different classes derived from this Base class "Acc" and
each of them has its own implementation of common_method(arg1, arg2);
class Acc_Der_1 : public Acc;
class Acc_Der_2 : public Acc;
.........................
.........................
class Acc_Der_8 : public Acc;
3) One Factory class that returns an object of one of the above 8 classes
based on some condition check.
class Acc_factory {
Acc* create_obj(uint32_t type) {
if (cond_1)
return new Acc_Der_1();
if (cond_2)
return new Acc_Der_2();
........................ /// so on .....
if (cond_8)
return new Acc_Der_8();
}
}
4) Finally a manage class which invokes the actual virtual method.
class Acc_Manager {
void main_func(uint32_t type) {
std::auto_ptr<Acc*> acc_obj (Acc_factory::get_instance->create_obj(type))
acc_obj->common_method(some_arg1, some_arg2);
}
};Now I need to extend my application to add 4 more derived classes from Acc
class Acc_Der_9 : public Acc;
class Acc_Der_10 : public Acc;
class Acc_Der_11 : public Acc;
class Acc_Der_12 : public Acc;
Each of them will have their own implementation of common_method(Arg1, arg2);
This will also force me to update the factory class to add 4 more condition check to return the correct derived class object.
Based on this requirement, is it feasible to use "Visitor Design Pattern". If so what are the pros and cons of it.
Looking...
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
you may use the factory pattern. then you can provide the create function with any new derived class and there is no need for enhancing a factory class.
3) One Factory class that returns an object of one of the above 8 classes
based on some condition check.
note, i used class name for key in factory, as it automatically is unique. of course you may change it (back) to uint32_t but that might violate the principle that a new class can be added solely by code of itself.
the new class will be "added" to factory by static initialization. after that you can create instances of the class by key.
Sara
3) One Factory class that returns an object of one of the above 8 classes
based on some condition check.
typedef Acc* (*create_derived_acc)();
class Acc_factory {
static std::map<std::string, create_derived_acc> factory;
public:
static Acc* create_obj(const std::string & classname)
{
std::map<std::string, create_derived_acc>::iterator f;
if ((f = factory.find(classname)) == factory.end())
{
// class is not registered
return NULL;
}
create_derived_acc func = f->second;
Acc* pacc = func();
return pacc;
}
static add_create_func(const std::string & cn, create_derived_acc f)
{
factory[cn] = f;
}
};
// acc_der_9.h
...
class Acc_Der_9 : public Acc
{
static bool added_to_factory;
...
public:
static Acc* create() { return new Acc_Der_9(); }
...
// acc_der_9.cpp
...
#include "acc_der_9.h"
bool Acc_Der_9::added_to_factory = Acc::add_create_func("Acc_Der_9", Acc_Der_9::create);
...note, i used class name for key in factory, as it automatically is unique. of course you may change it (back) to uint32_t but that might violate the principle that a new class can be added solely by code of itself.
the new class will be "added" to factory by static initialization. after that you can create instances of the class by key.
Sara
ASKER