Why do both the abstract class and interface exist in C#?

Well, an abstract class can specify some implemetation, but usually not all of it. (Having said which, it’s perfectly possible to provide an abstract class with no abstract members, but plenty of virtual ones which with “no-op” implementations). An interface provides no implementation, merely a contract.

You could certainly argue that if multiple inheritance of classes were permitted, interfaces would be largely pointless.

Personally I don’t get hung up on the whole “is-a” vs “can-do” distinction for inheritance. It never gives me as good an intuition about what to do as just playing around with different ideas and seeing which ones feel the most flexible. (Then again, I’m very much a “favour composition over inheritance” guy…)

EDIT: Just as the most convenient way of rebutting lbushkin’s third point in his comment… you can override an abstract method with a non-virtual one (in terms of not being able to override it further) by sealing it:

public abstract class AbstractBase
{
    public abstract void Foo();
}

public class Derived : AbstractBase
{
    public sealed override void Foo() {}
}

Classes deriving from Derived cannot override Foo any further.

I’m not in any way suggesting I want multiple inheritance of implementation – but if we did have it (along with its complexity) then an abstract class which just contained abstract methods would accomplish almost everything that an interface does. (There’s the matter of explicit interface implementation, but that’s all I can think of at the moment.)

Leave a Comment