Abstract Method in Non Abstract Class
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.
First, I think that what you're asking doesn't logically make sense. If you have an abstract
method, it basically means that the method is unfinished (as @ChrisSinclair pointed out). But that also means the whole class is unfinished, so it also has to be abstract
.
Or another way to put it: if you had an abstract
method on a class that wasn't abstract
, that would mean you had a method that cannot be called. But that means the method is not useful, you could remove it and it would all work the same.
Now, I'll try to be more concrete by using an example: imagine the following code:
Animal[] zoo = new Animal[] { new Monkey(), new Fish(), new Animal() };
foreach (Animal animal in zoo)
animal.MakeSound();
Here, Animal
is the non-abstract
base class (which is why I can put it directly into the array), Monkey
and Fish
are derived from Animal
and MakeSound()
is the abstract
method. What should this code do? You didn't state that clearly, but I can imagine few options:
-
You can't call
MakeSound()
on a variable typed asAnimal
, you can call it only using a variable typed as one of the derived classes, so this is a compile error.This is not a good solution, because the whole point of
abstract
is to be able to treat instances of derived classes as the base class, and still get behaviour that's specific to the derived class. If you want this, just put a normal (noabstract
,virtual
oroverride
) method into each derived class and don't do anything with the base class. -
You can't call
MakeSound()
on an object whose runtime type is actuallyAnimal
, so this is a runtime error (an exception).This is also not a good solution. C# is a statically typed language and so it tries to catch errors like “you can't call this method” at compile time (with obvious exceptions like reflection and
dynamic
), so making this into a runtime error wouldn't fit with the rest of the language. Besides, you can do this easily by creating avirtual
method in the base class that throws an exception.
To sum up, you want something that doesn't make much sense, and smells of bad design (a base class that behaves differently than its derived classes) and can be worked around quite easily. These are all signs of a feature that should not be implemented.
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...