Virtual methods are similar to abstract methods in base classes except their implementation on derived classes is optional. Also you could put logic in virtual method and override these in derived classes.
The virtual keyword is used to modify
a method or property declaration, in
which case the method or the property
is called a virtual member. The
implementation of a virtual member can
be changed by an overriding member in
a derived class.
When a virtual method is invoked, the
run-time type of the object is checked
for an overriding member. The
overriding member in the most derived
class is called, which might be the
original member, if no derived class
has overridden the member. (For more
information on run-time type and most
derived implementation, see 10.5.3
Virtual methods.)
By default, methods are non-virtual.
You cannot override a non-virtual
method.
You cannot use the virtual modifier
with the following modifiers:
staticabstractoverride
Virtual properties behave like
abstract methods, except for the
differences in declaration and
invocation syntax.
It is an error to use the virtual modifier on a static property.
A virtual inherited property can be overridden in a derived class by
including a property declaration that
uses the override modifier.
Virtual allows an inheriting class to replace a method that the base class then uses.
public class Thingy
{
public virtual void StepA()
{
Console.Out.WriteLine("Zing");
}
public void Action()
{
StepA();
Console.Out.WriteLine("A Thingy in Action.");
}
}
public class Widget : Thingy
{
public override void StepA()
{
Console.Out.WriteLine("Wiggy");
}
}
class Program
{
static void Main(string[] args)
{
Thingy thingy = new Thingy();
Widget widget = new Widget();
thingy.Action();
widget.Action();
Console.Out.WriteLine("Press any key to quit.");
Console.ReadKey();
}
}
When you run the Program your output will be:
Zing
A Thingy in Action.
Wiggy
A Thingy in Action.
Notice how even though Widget called the Action() method defined at the Thingy level, internally Thingy called Widget's StepA() method.
The basic answer is it gives inheritors of a class more flexibility. Of course, you've got to engineer your class well or it could weak havoc.
Even if you don't plan to derive from the class, marking the method virtual may be necessary in order to mock the class. Some mocking frameworks only allow you to mock virtual methods. Note that methods implementing an interface are virtual implicitly.
I use RhinoMocks which has this restriction and have taken to marking my methods virtual by default for just this reason. For me, this is probably the biggest reason to use virtual methods as the cases where inheritance comes into play are much less frequent.
Virtual methods are similar to abstract methods in base classes except their implementation on derived classes is optional. Also you could put logic in virtual method and override these in derived classes.
This link will provide you a better understanding with very easy example https://stackoverflow.com/a/2392656/3373865
Virtual Methods on MSDN
Virtual allows an inheriting class to replace a method that the base class then uses.
When you run the Program your output will be:
Notice how even though Widget called the Action() method defined at the Thingy level, internally Thingy called Widget's StepA() method.
The basic answer is it gives inheritors of a class more flexibility. Of course, you've got to engineer your class well or it could weak havoc.
A short question, a short answer! Qualify your method as "virtual" if you think you will inherit of the class it belongs to.
A longer answer: "virtual enables you to override, to give another meaning of your method in a derived class.
Even if you don't plan to derive from the class, marking the method virtual may be necessary in order to mock the class. Some mocking frameworks only allow you to mock virtual methods. Note that methods implementing an interface are virtual implicitly.
I use RhinoMocks which has this restriction and have taken to marking my methods virtual by default for just this reason. For me, this is probably the biggest reason to use virtual methods as the cases where inheritance comes into play are much less frequent.