Why is new/override required on abstract methods but not on virtual methods?

Sample 1:

abstract class ShapesClass
{
    abstract public int Area(); // abstract!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // Error: missing 'override' or 'new'
    {
        return x * y;
    }
}

The compiler will show this error: To make the current member override that implementation, add the override keyword. Otherwise add the new keyword

Sample 2:

class ShapesClass
{
    virtual public int Area() { return 0; } // it is virtual now!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // no explicit 'override' or 'new' required
    {
        return x * y;
    }
}

This will compile fine, by h开发者_如何学JAVAiding the method by default.

I fully understand the technical differences. However I wonder why the language was designed that way. Wouldn't it be better to have the same restriction in "Sample 2" as well? I mean in most cases if you create a method with the same name as in the parent class, you usually intent to override it. So I think explicitly stating Override/New would make sense on virtual methods as well.

Is there a design-wise reason for this behavior?

Update: The 2nd sample actually causes a warning. The first sample shows an error because the subclass is required to implement the abstract method. I didn't see the warning in VS.. makes perfectly sense to me now. Thanks.

Using either the C# 3.0 compiler as shipped in .NET 3.5 SP1, or the C# 4.0 compiler as shipped in .NET 4.0, I get the following error for your first example:

error CS0534: 'ConsoleApplication3.Square' does not implement inherited abstract member 'ConsoleApplication3.ShapesClass.Area()'

And the following warning for the second one:

warning CS0114: 'ConsoleApplication3.Square.Area()' hides inherited member 'ConsoleApplication3.ShapesClass.Area()'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.

In the first case it's an error because you aren't actually overriding the base method, which means there is no implementation for the abstract method in a concrete class. In the second case it's a warning because the code is technically correct, but the compiler suspects that it isn't what you meant. This is one of the reasons it's generally a good idea to enable the "treat warnings as errors" compilation setting.

So I can't repro your behaviour, and the behaviour of the compiler looks right to me. Which version of the compiler are you using?

Here's the answer straight from the C# spec.

...hiding an accessible name from an inherited scope causes a warning to be reported. In the example

class Base
{
    public void F() {}
}
class Derived: Base
{
    public void F() {}      // Warning, hiding an inherited name
}

the declaration of F in Derived causes a warning to be reported. Hiding an inherited name is specifically not an error, since that would preclude separate evolution of base classes. For example, the above situation might have come about because a later version of Base introduced an F method that wasn’t present in an earlier version of the class. Had the above situation been an error, then any change made to a base class in a separately versioned class library could potentially cause derived classes to become invalid. The warning caused by hiding an inherited name can be eliminated through use of the new modifier:

class Base
{
    public void F() {}
}
class Derived: Base
{
    new public void F() {}
}

The new modifier indicates that the F in Derived is “new”, and that it is indeed intended to hide the inherited member.

The difference is that the abstract method has to be overridden, but the virtual doesn't.

It's an error to inherit the abstract class (in a non-abstract class) without implementing all abstract members, but you only get a warning when inheriting from the class without specifying override or new for the virtual method.

I think in the first way you get the compiler error, because the abstract method is hidden and not implemented (so effectively your class is wrong, and it would be difficult to figure out why). In the second case you get only a warning, because the class is usable.

Versioning

At first glance, you may think that method hiding doesn’t appear particularly useful. There is a situation where you might need to use it, however. Let’s say you want to use a class named MotorVehicle that was written by another programmer, and you want to use this class to derive your own class. Further, let’s also assume you want to define an Accelerate() method in your derived class. For example:

public class Car : MotorVehicle
{
    // define the Accelerate() method
    public void Accelerate()
    {
        Console.WriteLine(“In Car Accelerate() method”);
        Console.WriteLine(model + “ accelerating”);
    }
}

Next, let’s suppose that the other programmer later modifies the MotorVehicle class and decides to add her own virtual Accelerate() method:

public class MotorVehicle
{
    // define the Accelerate() method
    public virtual void Accelerate()
    {
        Console.WriteLine(“In MotorVehicle Accelerate() method”);
        Console.WriteLine(model + “ accelerating”);
    }
}

The addition of this Accelerate() method by the other programmer causes a problem: The Accelerate() method in your Car class hides the inherited Accelerate() method now defined in their MotorVehicle class. Later, when you come to compile your Car class, it isn’t clear to the compiler whether you actually intended your method to hide the inherited method. Because of this, the compiler reports the following warning when you try to compile your Car class:

warning CS0114: ‘Car.Accelerate()’ hides inherited member ‘MotorVehicle.Accelerate()’. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.