Interfaces vs Abstract Classes in OOP: When to Use Which

The Age-Old Question

One of the most common interview questions for OOP developers: "What is the difference between an interface and an abstract class, and when do you use each?" Let's break it down clearly.

Abstract Classes

An abstract class can have both abstract (unimplemented) and concrete (implemented) methods. It can hold state (fields) and constructors.

abstract class Vehicle {
    public string Brand { get; set; }
    public int Year { get; set; }

    // Concrete method — shared behaviour
    public void StartEngine() => Console.WriteLine("Engine started.");

    // Abstract method — must be implemented by subclass
    public abstract int GetSeatingCapacity();
}

class Car : Vehicle {
    public override int GetSeatingCapacity() => 5;
}

class Bus : Vehicle {
    public override int GetSeatingCapacity() => 50;
}

Interfaces

An interface defines a contract. It contains only method signatures (and since C# 8, optional default implementations). A class can implement multiple interfaces.

interface IElectric {
    int BatteryCapacityKWh { get; }
    void Charge();
}

interface IConnected {
    void SyncWithApp();
}

class TeslaModel3 : Vehicle, IElectric, IConnected {
    public int BatteryCapacityKWh => 75;
    public override int GetSeatingCapacity() => 5;
    public void Charge() => Console.WriteLine("Charging...");
    public void SyncWithApp() => Console.WriteLine("Syncing with Tesla app...");
}

Key Differences

Rule of Thumb

• Use an abstract class when classes share common state or base behaviour ("is-a" relationship).
• Use an interface when you want to define capabilities that unrelated classes can share ("can-do" relationship).