Why does c# compiler force an abstract class to define (as opposed to implement) all the methods of the inherited interface ? why does it not mark unimplemented methods of an inherited interface as abstract on its own ?

I'm unable to appreciate this constraint, Is it because the language designers wanted the programmer of the abstract class to be more thoughtful while choosing a method to be - abstract, virtual or non virtual? Or is there something bigger to it?


Why C# Abstract classes must implement/declare inherited Interface methods?

While an abstract class cannot be instantiated, it can have implementation details. The designers of C# chose to force the user to either implement the functionality, or specifically state that the functionality inherited from the interface will not be implemented at this level. It's more of a "tell me you know you left this method out" type of check from the compiler.

C# always requires you to implement all interface methods. But it relaxes this restriction for abstract classes by permitting you to map interface methods onto abstract methods instead, rather than requiring you to provide a complete implementation.

  • Is there anything that says why the designers force users to implement the functionality or specifically state that the inherited functionality isn't implemented? I know that Java isn't like that - if I have an interface I with methods A and B, and an abstract class AC that implements I, I don't need to put anything about A and B in AC, but I would in a concrete class CC that extends AC. I'm not finding anything about technical advantages or disadvantages of one method over the other, although I can see that one is more verbose (and it's not Java in this case).
    – Thomas Owens
    May 8 '16 at 1:12
  • 2
    Not that I am aware. However, the C# team has a long history of requiring the programmer to be explicit about things, while also occasionally removing features from the language that they consider confusing. The most notorious example I can think of are switch case statements. C# does not allow fall-through, but you're still required to use break anyway. May 8 '16 at 2:52
  • @RobertHarvey, thanks... as I understand this language feature is built to support a more explicit programming philosophy (which I also endorse). I was curious to know if I'm overlooking any scenario where auto generated abstract function may cause an issue.
    – Kapoor
    May 8 '16 at 8:21
  • 2
    It's a nice feature that you have to tell the compiler that you know what you are doing. You have to say "I mean it". The compiler cannot distinguish between "I don't need this, so I didn't write it down", and "sorry, I forgot this" or "sorry, I misspelt the name".
    – gnasher729
    May 8 '16 at 9:45
  • 1
    C# is a language that tries to avoid surprising you. If you are inheriting from an abstract class in a third party API, you want to be able to see exactly which methods you need to implement. The last thing you want is to find out that one of the abstract ancestors of your class implements an interface that requires a method implementation you were not expecting. By forcing you to explicitly define your methods as abstract on the class it makes it easier to see what you need to do to implement the derived class.
    – Stephen
    May 11 '16 at 23:29

There is a little more to it, in that it is possible to have the same method name defined at different levels in the class ancestry - and for these to have different implementations.

Since this abstract class is implementing this interface, the compiler needs to know this classes implementation of this method.

I appreciate you could imply it is abstract in your example, but what about if your class also had a base class that already implemented this method.

  • If the base class implemented the interface method, you wouldn't need to abstract method definition on the derived class. Unless I'm misunderstanding you?
    – Stephen
    May 11 '16 at 23:33
  • A base class method that's not virtual is not cascaded up to this class, so you would then need the override keyword. May 12 '16 at 7:43
  • If a derived class implements an interface, and it has a base class which satisfies members of that interface, the interface contract is satisfied and no further action is necessary. Try it. If that method isn't marked as virtual, you would also need to use the new keyword to implement it in the derived class.
    – Stephen
    May 12 '16 at 22:16
  • Sorry, what I was trying to say, is that there are multiple scenarios, and if we have a default behaviour, it needs to work for all scenarios in the same way, otherwise it's not obvious what is happening. May 12 '16 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.