Virtual constructor idiom and factory design

c++, design-patterns, virtual-functions

Solution

The client doesn't necessarily have to be aware of the concrete type. For example, consider this hierarchy:

struct Base
{
    virtual ~Base();
    virtual Base * clone() const = 0;
    static Base * create(std::string const &);
    // ...
};

struct A : Base { A * clone() const { return new A(*this); } /* ... */ };
struct B : Base { B * clone() const { return new B(*this); } /* ... */ };
struct C : Base { C * clone() const { return new C(*this); } /* ... */ };

Base * Base::create(std::string const & id)
{
    if (id == "MakeA") return new A;
    else return new C;
};

In this case, the client can make and copy an existing object like so:

Base * p = Base::create("IWantB");  // or std::unique_ptr<Base> !
Base * q = p->clone();

In neither case does the client ever know the dynamic type of `*p` or `*q`.

Problem

In virtual constructor idiom there are virtual functions which returns new object OR copy of the object using virtual functions. But then to call these virtual functions polymorphic way, you must have object of that class created using actual constructor. In design pattern context, it means client is aware of the type of object before using polymorphic way of object creation?

Original source