How to set data members of derived product class in factory design pattern

Question

How to set data members of derived product class in factory design pattern?

class Factory
{
  public:
     product* Create(int type)
     {
        switch (type)
        {
           case 1:
             return new product1;
           break;
           case 2:
             return new product2;
           break;
        }
     }
};

class product
{
  int a;
  public :
  product(); 
  product(int a); 
  void seta (int a);
};

class product1:public product
{
  int b;
public:
  product1();
  product1(int a,int b):product(a), b(b) {}
  void setb (int b);
};

class product2:public product
{
  int c;
public:
  product2();
  product2(int a, int c):product(a), c(c) {}
  void setc (int c);
};


\\ client code 

void main()
{
  Factory f;
  product* p = f.create(1); // product1 created
  p->seta(2);
  // now how to set value b of product1
}

Note: if I down cast the p to p1 then there will be no point of using factory. Hence don't know how to use it.

EDIT : set method added for product, product1, product2. How to set value for b in main if product1 created using factory?

Answer 1

product could have some (pure) virtual methods. The effect of calling such methods depends on the dynamic type of the object, no downcast is necessary.

Answer 2

Ideally b would be set by the Factory during create. Is there any reason why that is not possible?

Failing that, you will probably have to set b via a virtual method on Product. Preferably via a virtual method that makes sense in the context of all Products.

Where does the value of b come from? For example, say the value comes from a file, it might make sense to have a virtual method Product::setThingsFromFile(string file). Override this virtual method in Product1 to set b from the file.

It might be a bit overkill, but you could consider using the Visitor Pattern and set b in the ConcreteVisitor::visit(Product1& product) method.

As a last resort you could add a virtual void Product::setB(int b) that is a no-op for most Products and only actually does anything for Product1 but it's not a good idea generally and is a good way of making a mess of Product.

Remember that the point of a Factory is that the client code shouldn't need to know what Product it is working with so if it needs to know it has a Product1 to set b then there is not much point using a Factory.