C# Inheritance — Missing Override Causes Silent Failure

Every non-trivial C# application has classes that share behaviour. A Customer and an Employee both have a name, an email, and an ID. A Circle and a Rectangle both have an area and a perimeter. If you write those shared properties and methods twice, you've just signed up for double the maintenance, double the bugs, and double the pain every time requirements change. Inheritance is how C# lets you centralise what's shared and specialise what's different — and it's one of the four pillars of object-oriented programming for a very good reason.

The real problem inheritance solves isn't code length — it's conceptual integrity. When a BankAccount and a SavingsAccount share a base, you're modelling the real world accurately. A savings account IS a bank account. That 'is-a' relationship is the signal that inheritance belongs here. Without it, you end up with bloated utility classes, copy-pasted logic, and systems where fixing one bug means hunting down five nearly-identical methods spread across the codebase.

By the end of this article you'll understand how to build a clean inheritance hierarchy in C#, know the difference between virtual, override, and new (and why confusing them causes silent bugs that are a nightmare to trace), and be able to explain to an interviewer exactly when inheritance is the right tool — and when it absolutely isn't.

What is Inheritance in C#?

Inheritance is the mechanism by which a class (the derived class) can reuse and extend the members of another class (the base class). C# supports single class inheritance — a derived class can have only one direct base class. However, interfaces can be inherited multiple times. The syntax uses a colon: class Derived : Base. All non-private members (fields, properties, methods, events) are inherited. Constructors and finalizers are not inherited, but the derived class must call a base constructor. The protected access modifier is commonly used to share members with derived classes while hiding them from external code.

The real power of inheritance comes from polymorphism: you can treat a derived object as an instance of its base type. Code that operates on a base class can work with any derived class without modification. This is a fundamental concept in object-oriented design.

using System;

namespace TheCodeForge.InheritanceDemo
{
    public class Vehicle
    {
        public string Make { get; set; }
        public string Model { get; set; }
        public int Year { get; set; }

        public Vehicle(string make, string model, int year)
        {
            Make = make;
            Model = model;
            Year = year;
        }

        public virtual void Start()
        {
            Console.WriteLine($"{Make} {Model} started.");
        }
    }

    public class Car : Vehicle
    {
        public int Doors { get; set; }

        public Car(string make, string model, int year, int doors)
            : base(make, model, year)
        {
            Doors = doors;
        }

        public override void Start()
        {
            Console.WriteLine($"{Make} {Model} (car with {Doors} doors) started.");
        }
    }

    public class Program
    {
        public static void Main()
        {
            Vehicle myVehicle = new Car("Toyota", "Camry", 2020, 4);
            myVehicle.Start();  // Output: Toyota Camry (car with 4 doors) started.
        }
    }
}

Base and Derived Classes: Syntax and Essentials

To create a derived class, place a colon and the base class name after the derived class name. The derived class automatically inherits all non-private members. However, constructors are not inherited: you must explicitly call a base constructor using : base(...). If the base class has a parameterless constructor, it's called implicitly — but it's still good practice to be explicit.

Access modifiers control visibility to derived classes. Use protected for members that should be accessible to derived types but not to external code. Use private protected (C# 7.2+) to allow access only to derived classes that are in the same assembly.

The base keyword inside a derived class allows you to access base class members even if they are overridden or hidden. It's especially useful when you want to extend a base method instead of replacing it completely.

using System;

namespace TheCodeForge.InheritanceDemo
{
    public class Animal
    {
        public string Name { get; set; }

        public Animal(string name)
        {
            Name = name;
        }

        public virtual void Speak()
        {
            Console.WriteLine("Animal makes a sound.");
        }
    }

    public class Dog : Animal
    {
        public Dog(string name) : base(name) { }

        public override void Speak()
        {
            base.Speak();  // Optional: call base implementation
            Console.WriteLine($"{Name} barks!");
        }
    }

    class Program
    {
        static void Main()
        {
            Dog dog = new Dog("Rex");
            dog.Speak();
        }
    }
}

Virtual, Override, and New: The Critical Difference

The virtual keyword in the base class declares a method that can be overridden by a derived class. The override keyword in the derived class replaces the base implementation for all callers, including those using the base type reference. This is the heart of polymorphism.

The new keyword, when applied to a method with the same signature, hides the base method instead of overriding it. This means that the method called depends on the compile-time type of the variable, not the runtime type. This is a common source of subtle bugs.

A method that is not marked virtual cannot be overridden. If you attempt to use override on a non-virtual method, you get a compile-time error. You can still use new to shadow it, but that's usually a design smell.

When you override a method, you can call the base implementation using base.MethodName(). This is useful when you want to add behaviour on top of the base class logic.

Constructors and Inheritance: Base Constructor Calls

Constructors are not inherited, but every derived class must ensure that the base class constructor is called. If the base class has a parameterless constructor, it's called implicitly. If the base class only has parameterized constructors, the derived class must explicitly call one using the colon syntax: public Derived(params) : base(params).

The base constructor runs before the derived constructor body. This means if you have initialization logic in both, the base runs first. Understanding this order is critical when properties are set in the base constructor and then modified in the derived constructor.

If the base constructor throws an exception, the derived constructor will not execute. This is a common cause of NullReferenceException when the derived class's field initializers run after the base constructor call (C# initializes fields before the base constructor call, but that's a subtle point).

Abstract Classes and Sealed Classes

An abstract class cannot be instantiated directly; it serves as a base class that defines a contract and optionally provides common implementation. Abstract methods have no body and must be overridden in any non-abstract derived class. Abstract classes can also have virtual methods, fields, constructors, etc.

A sealed class prevents further inheritance. It cannot be used as a base class. Sealing a class can help with security, performance (the JIT can devirtualize sealed class method calls), and design clarity.

Abstract classes are often used when you want to force derived classes to implement certain methods while providing shared base logic. They are similar to interfaces but can contain state (fields, properties with backing fields) and method bodies.

C# also allows you to seal individual methods in a derived class, preventing further overriding down the hierarchy.

using System;

namespace TheCodeForge.InheritanceDemo
{
    public abstract class Shape
    {
        public abstract double Area();

        public void Display()
        {
            Console.WriteLine($"Area: {Area():F2}");
        }
    }

    public sealed class Circle : Shape
    {
        public double Radius { get; }

        public Circle(double radius)
        {
            Radius = radius;
        }

        public override double Area() => Math.PI * Radius * Radius;
    }

    // This would cause compile error: 'cannot derive from sealed type'
    // public class ColoredCircle : Circle { }

    class Program
    {
        static void Main()
        {
            Shape shape = new Circle(5);
            shape.Display(); // Output: Area: 78.54
        }
    }
}

The “Is-A” Rule: Why You’ll Burn Yourself Without It

Inheritance isn't a code-sharing shortcut. It models an “is-a” relationship. A Dog is an Animal. A Manager is an Employee. If that sentence sounds wrong in plain English, don't use inheritance. I've cleaned up diffs where a junior inherited from List<T> just to get Add() for free. That's not an “is-a”; that's a design debt. The base class defines a contract. If your derived type can't fulfill every public member of the base without lying, you need composition or interfaces instead. Nothing kills a codebase faster than a Rectangle inheriting from Square because some tutorial said “reuse.” Real production: I once saw a SqlConnection wrapper inherit from Stream because the original author wanted Read(). Result: phantom open connections and NotSupportedException everywhere. Ask yourself: “Will this derived class ever violate a base class invariant?” If yes, stop. Use an interface. The compiler won't save you from bad semantics.

// io.thecodeforge
using System;

public class Employee
{
    public string Name { get; set; }
    public decimal CalculatePay() => 5000m;
}

public class Manager : Employee
{
    public decimal Bonus { get; set; }
    // Manager IS-A Employee — bonus extends pay, doesn't break it.
}

public class Client
{
    public string Name { get; set; }
    // NOT inheritance — a client is NOT an employee.
    // Use composition instead: public Employee? AccountManager { get; set; }
}

class Program
{
    static void Main()
    {
        Manager m = new Manager { Name = "Alice", Bonus = 2000m };
        Employee e = m; // Upcast works — Manager IS-A Employee.
        Console.WriteLine($"Pay: {e.CalculatePay()}"); // 5000 — invariant preserved.
    }
}

Types of Inheritance C# Actually Gives You (and One It Doesn't)

C# supports exactly three inheritance shapes directly. Single: one class, one parent. Multilevel: A -> B -> C — the chain you see in ORM entities or layered services. Hierarchical: one base, multiple children (e.g., PaymentMethod with CreditCard and PayPal). That's it. No multiple inheritance of classes. The compiler enforces this because diamond problems cause runtime heisenbugs. The other patterns you need? Interfaces. They solve the “what” without the “how” coupling. You can implement IDisposable, IComparable, and ISerialize on the same class—that's multiple inheritance of contract. In .NET 8, you can also do default interface methods for shared behavior without the base class baggage. Production example: a NotificationService that implements both IEmailSender and ISmsSender. No shared state, no base class coupling, just clean polymorphism. If you need true multiple inheritance of behavior, stop and refactor to composition or facade pattern.

// io.thecodeforge
using System;

// Single
public class Animal { }
public class Dog : Animal { }

// Multilevel
public class Vehicle { }
public class Car : Vehicle { }
public class Tesla : Car { }

// Hierarchical
public class PaymentMethod
{
    public abstract bool ProcessPayment(decimal amount);
}
public class CreditCard : PaymentMethod
{
    public override bool ProcessPayment(decimal amount) 
    { 
        Console.WriteLine("Credit card processed");
        return true; 
    }
}
public class PayPal : PaymentMethod
{
    public override bool ProcessPayment(decimal amount) 
    { 
        Console.WriteLine("PayPal processed");
        return true; 
    }
}

class Program
{
    static void Main()
    {
        PaymentMethod pm = new CreditCard();
        pm.ProcessPayment(100m); // Polymorphic dispatch.
    }
}

Sealed Record Types as Inheritance Alternative

C# 9 introduced record types, which are reference types with built-in value semantics. Sealed record types offer a compelling alternative to traditional inheritance when you need immutable data structures with structural equality. Unlike classes, records are designed for data-centric scenarios and cannot be inherited from when sealed. This prevents the fragile base class problem and ensures predictable behavior. To create a sealed record, use the sealed modifier on the record declaration. For example:

``csharp public sealed record Person(string FirstName, string LastName); ``

This record cannot be extended, but you can still use composition to add behavior. Records also support with expressions for non-destructive mutation, making them ideal for DTOs and domain events. In production, prefer sealed records over inheritance when you need immutable data carriers. They eliminate the need for complex inheritance hierarchies and reduce bugs from unintended polymorphism.

public sealed record Person(string FirstName, string LastName);

// Usage
var person1 = new Person("John", "Doe");
var person2 = person1 with { LastName = "Smith" };
Console.WriteLine(person1 == person2); // False (value equality)

// Cannot inherit: error CS0509
// public record Employee : Person { }

Default Interface Methods for Virtual Extension (C# 8+)

C# 8 introduced default interface methods, allowing interfaces to provide default implementations for their members. This enables a form of virtual extension without requiring base class inheritance. You can add new methods to an interface without breaking existing implementations. For example:

```csharp public interface ILogger { void Log(string message); void LogError(string message) => Log($"ERROR: {message}"); }

public class ConsoleLogger : ILogger { public void Log(string message) => Console.WriteLine(message); // LogError is inherited from the interface } ```

Classes that implement the interface can override the default method if needed. This is particularly useful for adding optional behavior to existing interfaces. However, default interface methods can lead to the diamond problem if multiple interfaces provide conflicting defaults. In production, use them sparingly to evolve public APIs without breaking changes. They are not a replacement for abstract classes but a tool for API versioning.

public interface ILogger
{
    void Log(string message);
    void LogError(string message) => Log($"ERROR: {message}");
}

public class ConsoleLogger : ILogger
{
    public void Log(string message) => Console.WriteLine(message);
}

// Usage
ILogger logger = new ConsoleLogger();
logger.LogError("Something went wrong"); // Output: ERROR: Something went wrong

Inheritance vs Composition vs Records Decision Guide

Choosing between inheritance, composition, and records depends on your design goals. Inheritance models an "is-a" relationship and is best for polymorphic behavior, but it creates tight coupling and fragile base classes. Composition models "has-a" relationships, promoting loose coupling and flexibility. Records are ideal for immutable data with value semantics. Use this guide:

• Inheritance: Use when you need polymorphic behavior and shared logic (e.g., base class with virtual methods). Avoid deep hierarchies.
• Composition: Use when you want to reuse behavior without coupling (e.g., dependency injection, strategy pattern). Prefer over inheritance for most scenarios.
• Records: Use for immutable data carriers (e.g., DTOs, events). Sealed records prevent inheritance.

Example: A Car class could inherit from Vehicle (is-a) or compose an Engine (has-a). For data, use a CarRecord record. In production, favor composition over inheritance to reduce complexity. Use records for data transfer and domain events.

// Inheritance
public class Vehicle { public virtual void Start() { } }
public class Car : Vehicle { public override void Start() { /* ... */ } }

// Composition
public class Engine { public void Ignite() { } }
public class Car { private Engine _engine = new(); public void Start() => _engine.Ignite(); }

// Record
public record CarRecord(string Make, string Model);