为什么我可以抽象覆盖抽象方法？

Question

I have an abstract base class:

abstract class Foo
{
    virtual void DoSomeStuff()
    {
        //Do Some Stuff
    }

    abstract void DoSomeCrazyStuff();
}

And another abstract class derived from that:

abstract class Bar : Foo
{
    abstract override void DoSomeStuff();

    abstract override void DoSomeCrazyStuff();
}

I understand why you'd want to abstract override DoSomeStuff() - it will require an new implementation for further derived classes. But I can't figure out why you would want to abstract override DoSomeCrazyStuff() . As far as I can tell, it's redundant - I'm pretty sure removing it would have zero negative impact.

Is there some use case where abstract override on an abstract does something useful? If not, why isn't there a compiler warning informing me that what I've wrote does nothing?

Answer 1

Why can I abstract override an abstract method?

For starters, there's no practical reason for preventing it. If it produced a compiler error, all that would do is make classes more brittle. For example:

abstract class Foo
{
    virtual void DoSomeStuff()
    {
        //Do Some Stuff
    }
}

abstract class Bar : Foo
{
    abstract override void DoSomeStuff();
}

If abstract override on abstract was illegal, changing DoSomeStuff on Foo to abstract would now prevent Bar from compiling. The abstract override is redundant, but there's no potential negative side effects, so the compiler is okay with this.

---

Why isn't there a compiler warning informing me that what I've wrote does nothing?

The compiler produces warnings for certain things that represent risk: non-explicit method hiding, unreachable code, using obsolete methods, etc. The only "problem" an unnecessary abstract override could indicate is that the code was not efficiently written. That's not something the compiler cares about.

---

Is there some use case where abstract override on an abstract does something useful?

Not functionally. However, there are a few use cases where you might intentionally do so:

• To improve the "readability" of the code. Having the redundant abstract override would serve as a reminder that the method is abstract.
• If future changes to the base class include providing a virtual implementation, you can preemptively prevent some classes from accessing that base class.
• If the abstract override is redundant because the base class was changed from a virtual implementation to abstract, it can safely be left alone.

Answer 2

By explicitly abstract override ing it in Bar you make sure it's going to be seen as abstract by Bar s descendents even though in the future in Foo it may be changed into a non-abstract one. Despite such change, Bar s descendants will work with the same contract.