Is there any need of Virtual Constructors? If so can any one post a scenario?
In what language? In C++ for example the constructors can not be virtual.
As always: look up at C++ FAQ lite: virtual functions.
It will explain not only "virtual constructor" but destructors/functions too!
This of course, if you wanted C++ in the first place...
The constructor can not be virtual by definition. At the time of constructor call there is no object created yet, so the polymorphism does not make any sense.
If you are talking about virtual destructors (in C++) then they should always be used if you are using your child classes polymorphically.
class A
{
~A();
}
class B : public A
{
~B();
}
A* pB = new B();
delete pB; // NOTE: WILL NOT CALL B's destructor
class A
{
virtual ~A();
}
class B : public A
{
virtual ~B();
}
A* pB = new B();
delete pB; // NOTE: WILL CALL B's destructor
Edit: Not sure why I've got a downvote for this (would be helpful if you left a comment...) but have a read here as well
http://blogs.msdn.com/oldnewthing/archive/2004/05/07/127826.aspx
Delphi is one language that supports virtual constructors.
Typically they would be used in a class factory type scenario where you create a meta type i.e. that is a type that describes a type. You would then use that meta type to construct a concrete example of your descendant class
Code would be something like....
type
MyMetaTypeRef = class of MyBaseClass;
var
theRef : MyMetaTypeRef;
inst : MyBaseClass;
begin
theRef := GetTheMetaTypeFromAFactory();
inst := theRef.Create(); // Use polymorphic behaviour to create the class
There are plenty of scenarios, for example if you want to create GUIs for more than one environment. Let's say you have classes for controls (“widgets”) but each environment actually has its own widget set. It's therefore logical to subclass the creation of these widgets for each environment. The way to do this (since, as has been unhelpfully pointed out, constructors can't actually be virtual in most languages), is to employ an abstract factory and the above example is actually the standard example used to describe this design pattern.
In C++, there's no reason for constructors to ever be virtual, because they are static functions. That means they're statically bound, so you have to identify the very constructor function you're calling in order to call it at all. There's no uncertainty and nothing virtual about it.
This also means that, no matter what, you need to know the class that your object is going to be. What you can do, however, is something like this:
Superclass *object = NULL;
if (condition) {
object = new Subclass1();
}
else {
object = new Subclass2();
}
object.setMeUp(args);
... have a virtual function and call it after constructon. This is a standard pattern in Objective-C, in which first you call the class's "alloc" method to get an instance, and then you call the initilializer that suits your use.
The person who mentioned the Abstract Factory pattern is probably more correct for C++ and Java though.