Abstract Class Theory

[Dan Sikorsky]

If we were to define all abstract methods in an abstract class, thereby
making that class non-abstract, and then override the heretofore 'abstract'
methods in a derived class, wouldn't that remove the need to have abstract
class types in C#?

Derived classes from abstract base classes must overrided the abstract
method defininition anyway, so why not just provide a complete definition
for the abstract method when defining the containing base class?

 

[Daniel O'Connell [C# MVP]]

If we were to define all abstract methods in an abstract class, thereby
making that class non-abstract, and then override the heretofore
'abstract'
methods in a derived class, wouldn't that remove the need to have abstract
class types in C#?

No, it would just achieve the same thing in a different way, without certain
benefits.

Derived classes from abstract base classes must overrided the abstract
method defininition anyway, so why not just provide a complete definition
for the abstract method when defining the containing base class?

The first thing this misses is that there is no complete definition to give.
An abstract method should not be one that can be implemented in the base
class, that misses the point. An abstract method is a method which is only
definable in a derived class.

The second is compiler enforcement of required overrides. By marking a
method abstract, you force the deriver to implement the method. A virtual
method has no such enforcement and removing abstract weakens the contract
and relegates required override information to documentation instead of
source code.

 

[Dan Sikorsky]

The purpose of my posting was to determine just what the benefits are for
inclusion of an abstract class type in the language. We could propose that
each class method have a default definition - if only to return true. Then
there would be no need for abstract methods, and no abstract classes. Again,
the derived class will be overriding, or even overloading, the base class
anyway.

If you don't know the definition of a method until the base class is
inherited by a derived class and the derived class overrides or overloads
it; just supply a default definition by returning true, or false.

What specific clear benefits to having abstract methods are there?

 

[Nicholas Paldino [.NET/C# MVP]]

Dan,

With an abstract method (on an abstract class), you force the derived
class to provide an implementation. Granted, I would usually write virtual
methods with a base implementation if it were possible. However, there are
a number of situations where a base implementation makes absolutely no
sense, and having a do-nothing method (in the form of a default virtual
implementation) doesn't add any benefit either.

Hope this helps.

 

[Jay B. Harlow [MVP - Outlook]]

Dan,
In addition to the other comments.

We could propose that
each class method have a default definition - if only to return true.

Abstract methods state there is *NO* default definition possible. Period.

In other words returning true or false is totally inappropriate! As you may
be introducing unexpected or undesired runtime behavior.

Also an Abstract class states that you cannot create an instance of the
class. Period.

The closest you can come to "correctly" implementing an abstract method in
an abstractless language would be for those methods to all raise
NotImplementedExceptions or NotSupportedExceptions. Unfortunately raising
the exception causes possibly hard to find runtime errors, where as the
abstract keyword clearly indicates a compile time error when the derived
class does not implement the method.

You can declare the constructors protected, to insure that no one created an
instance of the class, unfortunately the class itself could create an
instance of itself. Again you will get a compile error if any class tried to
instantiate an abstract class.

Hope this helps
Jay

 

[Nick Malik]

The purpose of my posting was to determine just what the benefits are for
inclusion of an abstract class type in the language. We could propose that
each class method have a default definition - if only to return true. Then
there would be no need for abstract methods, and no abstract classes. Again,
the derived class will be overriding, or even overloading, the base class
anyway.

If you don't know the definition of a method until the base class is
inherited by a derived class and the derived class overrides or overloads
it; just supply a default definition by returning true, or false.

What specific clear benefits to having abstract methods are there?

If you read into the Patterns literature, you can see that the requirement
to define an interface presents different benefits and costs than the option
of defining a base class. In many patterns, the creation of code in the
base class would defeat the pattern, or change the pattern to another, with
different attributes. Sometimes, the ONLY right answer is one in which the
abstract class is defined as purely abstract.

In addition, if you define two abstract classes, you can have a concrete
class inherit from both. On the other hand, you cannot have a concrete
class inherit from two base classes due to C#'s limitation against multiple
inheritance. Therefore, with the restriction against multiple inheritance,
the use of abstract classes is absolutely essential to the ability of a
developer to specify multiple interfaces for an object.

HTH,
--- Nick

 

[Daniel O'Connell [C# MVP]]

If you read into the Patterns literature, you can see that the requirement
to define an interface presents different benefits and costs than the
option
of defining a base class. In many patterns, the creation of code in the
base class would defeat the pattern, or change the pattern to another,
with
different attributes. Sometimes, the ONLY right answer is one in which
the
abstract class is defined as purely abstract.

In addition, if you define two abstract classes, you can have a concrete
class inherit from both. On the other hand, you cannot have a concrete
class inherit from two base classes due to C#'s limitation against
multiple
inheritance. Therefore, with the restriction against multiple
inheritance,
the use of abstract classes is absolutely essential to the ability of a
developer to specify multiple interfaces for an object.

Actually you are confusing abstract classes and interfaces.
A C# abstract class is a literal class and only one abstract class can be
inherited from just as any other base class acts. An interface, on the other
hand, I think more closely matches waht you are tying to get at here, where
any number of interfaces may be implemented by a given class.

 

[Daniel O'Connell [C# MVP]]

The purpose of my posting was to determine just what the benefits are for
inclusion of an abstract class type in the language. We could propose that
each class method have a default definition - if only to return true. Then
there would be no need for abstract methods, and no abstract classes.
Again,
the derived class will be overriding, or even overloading, the base class
anyway.

You could, but is there any clear benefit in that? All that is different is
that instead of an abstract modifier you get a form of expectation or
documentation that declares return type standards(since bool is not the only
return type). There is no complexity shift and abstract is arguably the
simpler pattern.

Also abstract forces implementation, as has been pointed out. A virtual
method is optional, an abstract is required.