Avatar of perlperl
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:
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); 
          }
 
      };

Open in new window


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.
C++

Avatar of undefined
Last Comment
sarabande

8/22/2022 - Mon
ASKER
perlperl

Hi evilrix, whenever you get a chance please look at this. I know you are the one of the expert in visitor patter ;)
evilrix

Looking...
ASKER CERTIFIED SOLUTION
evilrix

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
sarabande

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.

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);
...

Open in new window


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
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck