Explain the Liskov Substitution Principle with a C# example of a violation, and how you would detect and fix it.

1. Where it comes from

Barbara Liskov (1987) and Liskov & Wing (1994) defined behavioural subtyping: if S is a subtype of T, properties provable about T objects must hold for S objects. Bertrand Meyer's Design by Contract gives the practical rules: preconditions can't be strengthened, postconditions can't be weakened, invariants must be preserved.

2. Rectangle and square

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
    public int Area => Width * Height;
}

public class Square : Rectangle
{
    public override int Width  { get => base.Width;  set { base.Width = value; base.Height = value; } }
    public override int Height { get => base.Height; set { base.Width = value; base.Height = value; } }
}

Rectangle r = new Square();
r.Width = 4; r.Height = 5;
Console.WriteLine(r.Area);   // caller expects 20, gets 25

The implicit invariant of a mutable Rectangle is "setting Height doesn't change Width". Square can't honour it. Immutable shapes avoid the problem:

public interface IShape { double Area { get; } }
public sealed record Rectangle(double Width, double Height) : IShape { public double Area => Width * Height; }
public sealed record Square(double Side) : IShape { public double Area => Side * Side; }

3. Invariants in practice

public abstract class Account
{
    public decimal Balance { get; protected set; }
    // Invariant: Balance never goes below -OverdraftLimit
    public abstract decimal OverdraftLimit { get; }
    public virtual void Withdraw(decimal amount)
    {
        if (Balance - amount < -OverdraftLimit) throw new InvalidOperationException("Insufficient funds");
        Balance -= amount;
    }
}

A subclass overriding Withdraw without the check ("premium accounts can go anywhere") breaks the invariant that reporting and risk code rely on. If premium accounts need a different limit, express it through OverdraftLimit, not by bypassing the rule.

4. Contract tests

Using the IExporter interface from the code example (Task ExportAsync(Report r, CancellationToken ct)):

public abstract class ExporterContract
{
    protected abstract IExporter CreateSut();

    [Fact]
    public async Task Export_completes_for_a_valid_report()
    {
        var sut = CreateSut();
        await sut.ExportAsync(new Report("Sales"), CancellationToken.None);   // must not throw
    }

    [Fact]
    public async Task Export_honours_cancellation()
    {
        using var cts = new CancellationTokenSource();
        cts.Cancel();
        await Assert.ThrowsAnyAsync<OperationCanceledException>(
            () => CreateSut().ExportAsync(new Report("Sales"), cts.Token));
    }
}

public sealed class AdHocExporterTests : ExporterContract { protected override IExporter CreateSut() => new AdHocExporter(); }
public sealed class NightlyExporterTests : ExporterContract { protected override IExporter CreateSut() => new NightlyExporter(); }

Every implementation runs the same suite; a failing implementation is an LSP violation by definition. (The sample exporters in the code example return Task.CompletedTask and would fail the cancellation test, which is exactly the kind of gap contract tests reveal.)

5. LSP beyond inheritance

• Interfaces: any implementation of IRepository<T> must behave like one (consistency, cancellation, exceptions).
• Generics and variance: C# covariance (IEnumerable<out T>) and contravariance (IComparer<in T>) are type-level substitutability; LSP adds the behavioural part.
• Services and APIs: a new version of an HTTP API is a "subtype" of the old contract; breaking postconditions (fields becoming null) breaks clients just like a bad override.

6. The BCL compromise

ICollection<T>.IsReadOnly and Stream.CanSeek/CanWrite express capabilities at run time, so callers must check. Newer APIs prefer type-level capability (IReadOnlyList<T>, IReadOnlyCollection<T>, ReadOnlySpan<T>), so violations become compile errors instead of run-time exceptions.

7. Try it yourself

1. Write the mutable Rectangle/Square pair and a test SettingWidthThenHeight_GivesProductArea; run it for both.
2. Redesign with immutable IShape records and rerun.
3. Build the exporter contract test base class, run it against the sample exporters, and fix them so they honour cancellation.
4. Search your codebase for NotSupportedException and NotImplementedException in overrides and classify each.
5. Find callers that type-check for specific implementations and move that behaviour into the types.

// Violation: the base promises scheduling; one subtype cannot do it.
public abstract class ReportExporterBad
{
    public abstract Task ExportAsync(Report r, CancellationToken ct);
    public abstract void Schedule(Report r, TimeSpan every);
}

public sealed class AdHocExporterBad : ReportExporterBad
{
    public override Task ExportAsync(Report r, CancellationToken ct) => Task.CompletedTask;
    public override void Schedule(Report r, TimeSpan every) =>
        throw new NotSupportedException("Ad hoc exports cannot be scheduled"); // LSP smell
}

// Fix: split by capability so every implementation honours its contract.
public interface IExporter
{
    Task ExportAsync(Report r, CancellationToken ct);
}

public interface IScheduledExporter : IExporter
{
    void Schedule(Report r, TimeSpan every);
}

public sealed class AdHocExporter : IExporter
{
    public Task ExportAsync(Report r, CancellationToken ct) => Task.CompletedTask;
}

public sealed class NightlyExporter : IScheduledExporter
{
    public Task ExportAsync(Report r, CancellationToken ct) => Task.CompletedTask;
    public void Schedule(Report r, TimeSpan every) => Console.WriteLine($"{r.Name} every {every}");
}

// The scheduler can only receive exporters that support scheduling.
public sealed class Scheduler(IEnumerable<IScheduledExporter> exporters)
{
    public void ScheduleAll(Report r) { foreach (var e in exporters) e.Schedule(r, TimeSpan.FromDays(1)); }
}

public sealed record Report(string Name);