Why does C# allow for an abstract class with no abstract members?

Question

The C# spec, section 10.1.1.1 , states:

An abstract class is permitted (but not required) to contain abstract members.

This allows me to create classes like this:

public abstract class A
{
    public void Main() 
    {
        // it's full of logic!
    }
}

Or even better:

public abstract class A
{
    public virtual void Main() { }
}

public abstract class B : A
{
    public override sealed void Main()
    {
        // it's full of logic!
    }
}

This is really a concrete class; it's only abstract in so far as one can't instantiate it. For example, if I wanted to execute the logic in B.Main() I would have to first get an instance of B, which is impossible.

If inheritors don't actually have to provide implementation, then why call it abstract?

Put another way, why does C# allow an abstract class with only concrete members?

I should mention that I am already familiar with the intended functionality of abstract types and members.

Answer 1

Perhaps a good example is a common base class that provides shared properties and perhaps other members for derived classes, but does not represent a concrete object. For example:

public abstract class Pet
{
    public string Name{get;set;}
}

public class Dog : Pet
{
    public void Bark(){ ... }
}

All pets have names, but a pet itself is an abstract concept. An instance of a pet must be a dog or some other kind of animal.

The difference here is that instead of providing a method that should be overridden by implementors, the base class declares that all pets are composed of at least a Name property.

Answer 2

The idea is to force the implementor to derive from the class as it is intended to provide only a basis for a presumably more specialized implementation. So the base class, while not having any abstract members may only contain core methods an properties that can be used as a basis for extension.

For example:

public abstract class FourLeggedAnimal
{

    public void Walk()
    {
        // most 4 legged animals walk the same (silly example, but it works)
    }

    public void Chew()
    {

    }
}

public class Dog : FourLeggedAnimal
{
    public void Bark()
    {
    }
}

public class Cat : FourLeggedAnimal
{
    public void Purr()
    {
    }
}

Answer 3

I think a slightly more accurate representation of your question would be: Why does C# allow an abstract class with only concrete members?

The answer: There's no good reason not to. Perhaps someone out there has some organizational structure where they like to have a noninstantiatable class at the top, even if a class below it just inherits and adds nothing. There's no good reason not to support that.

Answer 4

You said it -- because you can't instantiate it; it is meant to be a template only.

It is not "really a concrete class" if you declare it as abstract. That is available to you as a design choice.

That design choice may have to do with creating entities that are (at risk of mixing the terminology) abstractions of real-world objects, and with readability. You may want to declare parameters of type Car , but don't want objects to be declarable as Car -- you want every object of type Car to be instantiated as a Truck , Sedan , Coupe , or Roadster . The fact that Car doesn't require inheritors to add implementation does not detract from its value as an abstract version of its inheritors that cannot itself be instantiated.

Answer 5

Abstract means providing an abstraction of behaviour. For example Vehicle is an abstract form. It doesn't have any real world instance, but we can say that Vehicle has accelerating behaviour. More specifically Ford Ikon is a vehicle, and Yamaha FZ is a vehicle. Both these have accelerating behaviour.

If you now make this in the class form. Vehicle is abstract class with Acceleration method. While you may/ may not provide any abstract method. But the business need is that Vehicle should not be instantiated. Hence you make it abstract. The other two classes - Ikon and FZ are concrete classes deriving from Vehicle class. These two will have their own properties and behaviours.

Answer 6

With regards to usage, using abstract on a class declaration but having no abstract members is the same as having the class public but using protected on its constructors. Both force the class to be derived in order for it to be instantiated.

However, as far as self-documenting code goes, by marking the class abstract it informs others that this class is never meant to be instantiated on its own, even if it has no virtual or abstract members. Whereas protecting the constructors makes no such assertion.

Answer 7

The compiler does not prevent implementation-logic, but in your case I would simply omit abstract ?! BTW some methods could be implemented with { throw Exception("must inherit"); } { throw Exception("must inherit"); } and the compiler could not distinguish fully implemented classes and functions including only throw .

Answer 8

Here's a potential reason:

Layer Supertype

It's not uncommon for all the objects in a layer to have methods you don't want to have duplicated throughout the system. You can move all of this behavior into a common Layer Supertype.

-- Martin Fowler

There's no reason to prevent having only concrete methods in an abstract class - it's just less common. The Layer Supertype is a case where this might make sense.

Answer 9

I see abstract classes serving two main purposes:

• An incomplete class that must be specialized to provide some concrete service. Here, abstract members would be optional . The class would provide some services that the child classes can use and could define abstract members that it uses to provide its service, like in the Template Method Pattern . This type of abstract class is meant to create an .。

• A class that only provides static .。 In this case, abstract members don't make sense at all. C# supports this notion with static classes , they are implicitly abstract and sealed. This can also be achieved with a sealed class with a private constructor.