C# Inheritance: base, virtual, override, sealed and Polymorphism

Inheritance lets one class build on another. The derived class gets the base class's members, adds its own, and may replace the behavior the base class allows it to replace. Combined with virtual methods, it gives you polymorphism: code written against the base class runs the right derived behavior without knowing which derived class it has.

Deriving a class

Put the base class after a colon. The derived class has everything the base class has, plus what it declares:

using System;

class Vehicle
{
    public string Plate { get; }
    public int Km { get; private set; }

    public Vehicle(string plate) { Plate = plate; }

    public void Drive(int km) { Km += km; }
}

class Taxi : Vehicle
{
    public int Fares { get; private set; }

    public Taxi(string plate) : base(plate) { }

    public void Pickup(int km)
    {
        Drive(km);      // inherited method
        Fares++;
    }
}

class Program
{
    static void Main()
    {
        var taxi = new Taxi("TX-19");
        taxi.Pickup(12);
        taxi.Pickup(5);
        taxi.Drive(3);   // callers can use inherited members too

        Console.WriteLine($"{taxi.Plate}: {taxi.Km} km, {taxi.Fares} fares");
        Console.WriteLine(taxi is Vehicle);
    }
}

Output:

TX-19: 20 km, 2 fares
True

What a derived class does and does not get:

• Inherited: fields, properties, methods, events and nested types. Everything is physically in the object.
• Accessible: only what the base allows: public, protected and internal members. A private member of Vehicle exists inside every Taxi but Taxi's code cannot name it. That is why Km has a private set: Taxi can read it, and changes it only through Drive.
• Not inherited: constructors. Taxi must declare its own and chain to one of Vehicle's with : base(plate). The constructors page shows the order the two run in.

Every class ultimately derives from object, which is why every object has ToString(), Equals() and GetHashCode().

virtual and override

A base class marks a method virtual to say "derived classes may provide their own version". A derived class replaces it with override. Inside the override, base.Method() calls the base class's version.

using System;
using System.Collections.Generic;

class Notification
{
    public string To { get; }
    public Notification(string to) { To = to; }

    public virtual string Channel => "generic";

    public virtual string Render(string message) => $"[{Channel}] to {To}: {message}";
}

class Email : Notification
{
    public Email(string to) : base(to) { }
    public override string Channel => "email";

    public override string Render(string message) =>
        base.Render(message) + "\n  (unsubscribe link appended)";
}

class Sms : Notification
{
    public Sms(string to) : base(to) { }
    public override string Channel => "sms";

    // SMS messages are cut to 20 characters here to keep the demo short.
    public override string Render(string message) =>
        base.Render(message.Length > 20 ? message.Substring(0, 20).TrimEnd() + "..." : message);
}

class Program
{
    static void Main()
    {
        var outbox = new List<Notification>
        {
            new Email("lea@example.com"),
            new Sms("+351 912 000 111"),
            new Notification("ops-team"),
        };

        foreach (Notification n in outbox)
            Console.WriteLine(n.Render("Your order 1042 has shipped today"));
    }
}

Output:

[email] to lea@example.com: Your order 1042 has shipped today
  (unsubscribe link appended)
[sms] to +351 912 000 111: Your order 1042 has...
[generic] to ops-team: Your order 1042 has shipped today

The loop variable is typed Notification, and yet each object renders its own way. That is polymorphism: the call n.Render(...) is resolved at run time from the object's actual type. Notice also that base.Render in Email uses Channel, which is itself virtual, so the base method prints email, not generic. A virtual call inside the base class still reaches the override.

Properties can be virtual too, as Channel shows. Fields cannot.

The compiler holds you to both keywords. Writing override on a method that is not virtual is error CS0506 ("cannot override inherited member ... because it is not marked virtual, abstract, or override"). Leaving override off when the base method is virtual is only a warning, and it changes the meaning completely, as the next section shows.

new vs override: hiding instead of overriding

If a derived class declares a method with the same signature as a base method without writing override, it hides the base method. The compiler warns (CS0114 for a virtual base method, CS0108 otherwise) and suggests the new keyword, which silences the warning but keeps the hiding behavior:

using System;

class Report
{
    public virtual string Title() => "Report";
}

class SalesReport : Report
{
    public override string Title() => "Sales report";
}

class DraftReport : Report
{
    public new string Title() => "Draft report";
}

class Program
{
    static void Main()
    {
        Report a = new SalesReport();
        Report b = new DraftReport();
        DraftReport c = new DraftReport();

        Console.WriteLine(a.Title());
        Console.WriteLine(b.Title());
        Console.WriteLine(c.Title());
    }
}

Output:

Sales report
Report
Draft report

b and c are the same kind of object, yet they print different titles. With new, the method chosen depends on the variable's type, decided at compile time. Code that handles reports as Report (a list, a method parameter, a framework callback) never sees DraftReport.Title. That is almost never what you want. Use override for polymorphism; new exists mainly for the case where a base class you do not control adds a member whose name collides with one you already have.

sealed

sealed on a class forbids deriving from it:

sealed class Invoice { }
class CorrectedInvoice : Invoice { }
// error CS0509: 'CorrectedInvoice': cannot derive from sealed type 'Invoice'

string is sealed, as are many framework types. On an override, sealed stops the chain at that level:

class Shape { public virtual string Name() => "shape"; }
class Square : Shape { public sealed override string Name() => "square"; }
class Tile : Square { public override string Name() => "tile"; }
// error CS0239: 'Tile.Name()': cannot override inherited member 'Square.Name()' because it is sealed

Designing a class for inheritance takes work: deciding what is virtual, what derived classes may rely on, what order things happen in. A class that was not designed that way is safer sealed, and sealing can be undone later without breaking anyone, while unsealing cannot be taken back once others derive from you. Calls to members of sealed classes can also be slightly faster, because the runtime knows no override exists.

One base class, many interfaces

A C# class has exactly one base class. class Admin : User, Employee is error CS1721 ("cannot have multiple base classes"). A class can, however, implement any number of interfaces alongside its base class:

class Admin : User, IAuditable, IComparable<Admin>
{
    // base class first, then interfaces, in any order
}

Use a base class for "is a kind of, and shares implementation with", and interfaces for "can do". When the base class only exists to force derived classes to fill in some methods, an abstract class is the tool.

Casting up and down the hierarchy

A derived object can always be used where its base type is expected. That upcast is implicit and cannot fail. Going the other way, a downcast, needs an explicit cast and fails at run time if the object is not of that type:

using System;

class Animal { public string Name; }
class Dog : Animal { public void Fetch() => Console.WriteLine($"{Name} fetches the ball"); }
class Cat : Animal { }

class Program
{
    static void Main()
    {
        Animal pet = new Dog { Name = "Rex" };   // upcast: implicit
        Animal other = new Cat { Name = "Tom" };

        Dog d = (Dog)pet;                        // downcast: explicit, succeeds
        d.Fetch();

        try
        {
            Dog wrong = (Dog)other;              // the object is a Cat
        }
        catch (InvalidCastException)
        {
            Console.WriteLine("InvalidCastException: Tom is not a Dog");
        }

        Dog maybe = other as Dog;                // as: null instead of an exception
        Console.WriteLine(maybe == null);

        if (pet is Dog dog)                      // is: test and cast in one step
            dog.Fetch();
    }
}

Output:

Rex fetches the ball
InvalidCastException: Tom is not a Dog
True
Rex fetches the ball

Writing Dog d = pet; without the cast is a compile error (CS0266: "An explicit conversion exists (are you missing a cast?)"), because the compiler only knows pet is some Animal. Prefer is with a variable when the object might be of another type, and a plain cast only when anything else would be a bug. Frequent downcasting is a design smell: it usually means the behavior belongs in a virtual method on the base class. The pattern matching page covers the is forms in full.

Inheritance and collections

Polymorphism works element by element, but generic collections of a derived type are not collections of the base type: List<Animal> animals = new List<Dog>(); does not compile, because the list would then accept a Cat. Read-only views are covariant, so IEnumerable<Animal> animals = new List<Dog>(); is fine. The generics page explains why.

Common mistakes

• Forgetting override. The method compiles with a warning and silently hides instead of overriding. Treat CS0114 as an error.
• Making everything virtual. Each virtual member is a promise to derived classes about when it is called and what it may assume. Only mark the extension points you intend.
• Deep hierarchies. Three or four levels of inheritance make it hard to know which version of a method runs. Composition, a class holding another object and calling it, is often simpler than a new level.
• Calling virtual methods from a constructor. The override runs before the derived constructor's body, so any field that body assigns still holds its default value.
• Using inheritance only to reuse code. If a Stack inherits from List, callers can Insert into the middle of your stack. Hold a List in a private field instead.