Abstract Classes

Photo by Photo Boards on Unsplash

Our discovery into OO class-based Inheritance continues. See previous articles here and here. An integral part of Inheritance is this idea of the ‘Abstract Base Class’ or simply ‘Abstract Class’. 

So, what is an Abstract Class anyway?

An Abstract Class is a base class that 

1. has been marked with the abstract keyword, and
2. cannot be instantiated.

If we cannot create an instance of an abstract class, then what use is it? 

Even though we cannot directly instantiate an abstract class, we can instantiate subclasses.

Let’s go back to our recent Dog/Chihuahua example. We’ll make a couple of changes: We declare Dog as an abstract class and BarkingSound as an abstract property of Dog:

  public abstract class Dog
  {
     protected abstract string BarkingSound { get; }

     public void Bark()
     {
        Console.WriteLine(BarkingSound);
     }
  }

Notice how the abstract property BarkingSound no longer has an implementation. It’s a property getter declaration without a definition. Derived class Chihuahua is forced to implement BarkingSound:

  public class Chihuahua : Dog
  {
     protected override string BarkingSound => "Yap! Yap!";
  }

The override keyword indicates an implementation for an abstract member.

As anticipated, we can no longer instantiate abstract class Dog:

An abstract class may have zero or more abstract methods, getter and setter properties. It is possible to define abstract classes entirely without abstract members. 

Subclasses must implement all abstract members. In this way, abstract classes are very similar to interfaces. Interfaces and abstract classes only containing abstract methods – i.e. nothing concrete – are functionally equivalent. 

OK. Why have abstract classes? 

Just like interfaces, they provide structure – interfaces provide it to implementers while abstract classes provide it to subclasses. Both are therefore important in building pluggable, modular software systems. The only difference between interfaces and abstract classes is that abstract classes can, but need not, contain concrete methods (and properties) whether they be private, public or protected. Interfaces are purely abstract. As such, they may contain no concrete definitions. Abstract classes are a halfway house – allowing abstract and concrete methods to live together under the same roof. 

When would we use abstract classes?

They are handy when it doesn’t make sense to allow a program to construct instances of a type, like Dog, that always comes in specific flavours – e.g. Chihuahua, Rottweiler, or Dachshund. Similarly, we would be unlikely to instantiate a plain-vanilla PaymentGateway. We would be more likely to instantiate concrete classes that correspond to particular payment gateway providers: PaypalPaymentGateway or StripePaymentGateway. Base class PaymentGateway should probably be declared as abstract to prevent it accidentally being instantiated.

Fair enough. But isn’t this very similar to how an interface behaves? Yes, it is. I will go into the difference between abstract classes and interfaces and how I like to use them next time.