What are differences between declaring a method in a base type \"virtual
\" and then overriding it in a child type using the \"override
\" keyword as
The new
keyword actually creates a completely new member that only exists on that specific type.
For instance
public class Foo
{
public bool DoSomething() { return false; }
}
public class Bar : Foo
{
public new bool DoSomething() { return true; }
}
The method exists on both types. When you use reflection and get the members of type Bar
, you will actually find 2 methods called DoSomething()
that look exactly the same. By using new
you effectively hide the implementation in the base class, so that when classes derive from Bar
(in my example) the method call to base.DoSomething()
goes to Bar
and not Foo
.
Not marking a method with anything means: Bind this method using the object's compile type, not runtime type (static binding).
Marking a method with virtual
means: Bind this method using the object's runtime type, not compile time type (dynamic binding).
Marking a base class virtual
method with override
in derived class means: This is the method to be bound using the object's runtime type (dynamic binding).
Marking a base class virtual
method with new
in derived class means: This is a new method, that has no relation to the one with the same name in the base class and it should be bound using object's compile time type (static binding).
Not marking a base class virtual
method in the derived class means: This method is marked as new
(static binding).
Marking a method abstract
means: This method is virtual, but I will not declare a body for it and its class is also abstract (dynamic binding).
My version of explanation comes from using properties to help understand the differences.
override
is simple enough, right ? The underlying type overrides the parent's.
new
is perhaps the misleading (for me it was). With properties it's easier to understand:
public class Foo
{
public bool GetSomething => false;
}
public class Bar : Foo
{
public new bool GetSomething => true;
}
public static void Main(string[] args)
{
Foo foo = new Bar();
Console.WriteLine(foo.GetSomething);
Bar bar = new Bar();
Console.WriteLine(bar.GetSomething);
}
Using a debugger you can notice that Foo foo
has 2 GetSomething
properties, as it actually has 2 versions of the property, Foo
's and Bar
's, and to know which one to use, c# "picks" the property for the current type.
If you wanted to use the Bar's version, you would have used override or use Foo foo
instead.
Bar bar
has only 1, as it wants completely new behavior for GetSomething
.
I always find things like this more easily understood with pictures:
Again, taking joseph daigle's code,
public class Foo
{
public /*virtual*/ bool DoSomething() { return false; }
}
public class Bar : Foo
{
public /*override or new*/ bool DoSomething() { return true; }
}
If you then call the code like this:
Foo a = new Bar();
a.DoSomething();
NOTE: The important thing is that our object is actually a Bar
, but we are storing it in a variable of type Foo
(this is similar to casting it)
Then the result will be as follows, depending on whether you used virtual
/override
or new
when declaring your classes.
The difference between the override keyword and new keyword is that the former does method overriding and the later does method hiding.
Check out the folllowing links for more information...
MSDN and Other
Beyond just the technical details, I think using virtual/override communicates a lot of semantic information on the design. When you declare a method virtual, you indicate that you expect that implementing classes may want to provide their own, non-default implementations. Omitting this in a base class, likewise, declares the expectation that the default method ought to suffice for all implementing classes. Similarly, one can use abstract declarations to force implementing classes to provide their own implementation. Again, I think this communicates a lot about how the programmer expects the code to be used. If I were writing both the base and implementing classes and found myself using new I'd seriously rethink the decision not to make the method virtual in the parent and declare my intent specifically.