c# of call to how Abstract Method in Non Abstract Class

4 Answers

So, you want to allow

class C { abstract void M(); }

to compile. Suppose it did. What do you then want to happen when someone does

new C().M();

? You want an execution-time error? Well, in general C# prefers compile-time errors to execution-time errors. If you don't like that philosophy, there are other languages available...

non abstract method in abstract class c#

I want to know the reason behind the design of restricting Abstract Methods in Non Abstract Class (in C#).

I understand that the class instance won't have the definition and thus they wont be callable, but when static methods are defined,they are excluded from the instance too. Why abstract methods are not handled that way, any specific reason for the same?

They could be allowed in concrete class and the deriving class can be forced to implement methods, basically that is what, is done in case of abstract methods in an abstract class.

You can achieve what you want using "virtual" methods but using virtual methods can lead to more runtime business logic errors as a develop is not "forced" to implement the logic in the child class.

I think there's a valid point here. An abstract method is the perfect solution as it would "enforce" the requirement of defining the method body in children.

I have come across many many situations where the parent class had to (or it would be more efficient to) implement some logic but "Only" children could implement rest of the logic"

So if the opportunity was there I would happily mix abstract methods with complete methods.

@AakashM, I appreciate C# prefers compile time errors. So do I. And so does anybody. This is about thinking out-of-the-box.

And supporting this will not affect that.

Let's think out of the box here, rather than saying "hurrah" to big boy decisions.

C# compiler can detect and deny someone of using an abstract class directly because it uses the "abstract" keyword.

C# also knows to force any child class to implement any abstract methods. How? because of the use of the "abstract" keyword.

This is pretty simple to understand to anyone who has studied the internals of a programming language.

So, why can't C# detect an "abstract" keyword next to a method in a normal class and handle it at the COMPILE TIME.

The reason is it takes "reworking" and the effort is not worth supporting the small demand.

Specially in an industry that lacks people who think out of the boxes that big boys have given them.

So the answers above are correct: having abstract methods makes the class inherently abstract. If you cannot instance part of a class, then you cannot instance the class itself. However, the answers above didn't really discuss your options here.

First, this is mainly an issue for public static methods. If the methods aren't intended to be public, then you could have protected non-abstract methods, which are allowed in an abstract class declaration. So, you could just move these static methods to a separate static class without much issue.

As an alternative, you could keep those methods in the class, but then instead of having abstract methods, declare an interface. Essentially, you have a multiple-inheritance problem as you want the derived class to inherit from two conceptually different objects: a non-abstract parent with public static members, and an abstract parent with abstract methods. Unlike some other frameworks, C# does permit multiple inheritance. Instead, C# offers a formal interface declaration that is intended to fill this purpose. Moreover, the whole point of abstract methods, really, is just to impose a certain conceptual interface.

I have a scenario very similar to what the OP is trying to achieve. In my case the method that I want to make abstract would be a protected method and would only be known to the base class. So the "new C().M();" does not apply because the method in question is not public. I want to be able to instantiate and call public methods on the base class (therefore it needs to be non-abstract), but I need these public methods to call a protected implementation of the protected method in the child class and have no default implementation in the parent. In a manner of speaking, I need to force descendants to override the method. I don't know what the child class is at compile time due to dependency injection.

My solution was to follow the rules and use a concrete base class and a virtual protected method. For the default implementation, though, I throw a NotImplementedException with the error "The implementation for method name must be provided in the implementation of the child class."

protected virtual void MyProtectedMethod() 
  throw new NotImplementedException("The implementation for MyProtectedMethod must be provided in the implementation of the child class."); 

In this way a default implementation can never be used and implementers of descendant implementations will quickly see that they missed an important step.