Inheritance

Inheritance lets one class build on another. The new class starts with everything the original had — its properties, its methods — and adds or changes what it needs. The original is the base class; the new one is the derived class.

The relationship it models is "is a kind of". A manager is a kind of employee. A savings account is a kind of account. When that sentence is true of the real thing you are modelling, inheritance describes it accurately.

It is worth saying plainly at the start: inheritance is frequently reached for as a way to avoid retyping code, and that is the use it handles worst. This lesson teaches the mechanism and then makes the case for a different default.

public class Employee
{
    public string Name { get; }
    public string Role { get; }

    public Employee(string name, string role)
    {
        Name = name;
        Role = role;
    }

    public string Describe()
    {
        return $"{Name} ({Role})";
    }
}

public class Manager : Employee
{
    public int DirectReports { get; }

    public Manager(string name, int directReports)
        : base(name, "Manager")
    {
        DirectReports = directReports;
    }
}

Manager priya = new Manager("Priya", 6);

Console.WriteLine(priya.Describe());        // Priya (Manager)
Console.WriteLine(priya.DirectReports);     // 6

Employee asEmployee = priya;                // a Manager is usable anywhere an Employee is

• public class Manager : Employee declares Employee as the base class. A class can have only one base class in C#.
• Manager does not redeclare Name, Role or Describe. It has them because it inherits them.
• : base(name, "Manager") calls the base constructor. It runs before the Manager constructor body, because the base part of the object has to be set up first.
• The last line is the property that makes inheritance useful: a Manager can be treated as an Employee. Code written against Employee works with every kind of employee you ever add.

public class OrderBook
{
    protected readonly List<Order> Stored = new List<Order>();

    public virtual void Add(Order order)
    {
        Stored.Add(order);
    }

    public virtual void AddMany(List<Order> orders)
    {
        foreach (Order order in orders)
        {
            Add(order);            // an internal detail: AddMany routes through Add
        }
    }
}

public class CountingOrderBook : OrderBook
{
    public int AddedCount { get; private set; }

    public override void Add(Order order)
    {
        AddedCount++;
        base.Add(order);
    }

    public override void AddMany(List<Order> orders)
    {
        AddedCount += orders.Count;
        base.AddMany(orders);      // which calls Add, which counts again
    }
}

• virtual on a base method means a derived class is allowed to replace it. override on the derived method is how it does so. The next lesson covers both properly.
• Read CountingOrderBook on its own and it looks correct. Both methods count what they add and then hand off to the base.
• Add three orders through AddMany and AddedCount becomes six. AddMany counted three, then base.AddMany called the overridden Add three more times.
• The author of CountingOrderBook could not have known this without reading the base class's source. Nothing in the public signature of AddMany says "this calls Add internally".
• Fixing it means removing the override of AddMany — which is only correct while the base keeps routing through Add. A later refactor of the base class, changing nothing public, breaks the subclass again.

That is the fragile base class problem. A derived class does not depend only on the base class's public surface; it depends on how the base class is built inside — which methods call which, in what order, and what state they expect. Those internal details are not documented and are not part of any contract, so they change freely. When they change, subclasses break, and the break is often silent.

The effect compounds. Once a class has subclasses, its internal call structure has quietly become part of its interface, and the author can no longer safely refactor it. Inheritance is the tightest coupling C# offers between two classes, and it is the only one you cannot loosen later without rewriting both sides.

public class CountingOrderBook
{
    private readonly OrderBook _inner;

    public int AddedCount { get; private set; }

    public CountingOrderBook(OrderBook inner)
    {
        _inner = inner;
    }

    public void Add(Order order)
    {
        AddedCount++;
        _inner.Add(order);
    }

    public void AddMany(List<Order> orders)
    {
        AddedCount += orders.Count;
        _inner.AddMany(orders);
    }
}

• No base class. CountingOrderBook holds an OrderBook in a private field and forwards work to it. This is composition: "has a" rather than "is a".
• The double-counting cannot happen. _inner.AddMany may call Add internally, but that is OrderBook's own Add, not this class's, so it is invisible here.
• The only thing this class depends on is OrderBook's public methods. OrderBook can be rewritten inside however its author likes.
• The cost is visible in the code: two forwarding methods that inheritance would have supplied free. That is the trade you are making — a small amount of typing in exchange for not depending on someone else's internals.