Composition or inheritance: how do you decide which to use in a C# design? Walk through the criteria you apply, a case where inheritance is the right answer, and how you would refactor a hierarchy that has gone wrong.

How I would answer this in an interview

My default is composition, and I use inheritance only when a set of criteria holds. The question isn't "is-a vs has-a" in English — almost anything can be phrased both ways — it's whether the subtype is truly substitutable, whether the variation is one stable axis, and whether I control the base class. I'd walk through the criteria, a case where inheritance is right, and how I'd refactor a hierarchy gone wrong.

1. The criteria I apply

I choose inheritance only if all of these are true:

1. Substitutability (Liskov): every subtype can be used wherever the base is expected, honouring all its contracts — no NotSupportedException, no weaker guarantees.
2. A stable, single axis of variation: subtypes vary in one dimension that's unlikely to multiply (not format × channel × schedule).
3. Shared invariants and real shared behaviour belong in the base (not just a few helper methods).
4. I control the base class (same team/repo), or it's a framework extension point designed for inheritance.
5. The relationship is fixed for an object's lifetime (an object can't change its class at run time).
6. The hierarchy stays shallow (one or two levels).

Otherwise I prefer composition: inject collaborators (strategies, policies, decorators), which gives:

• variation along multiple independent axes without class explosion,
• run-time selection and replacement,
• coupling only to public contracts (no fragile base class),
• easier testing of each part.

2. A case where inheritance is right

Framework extension points designed for it:

public sealed class OutboxPublisher(IServiceScopeFactory scopes, ILogger<OutboxPublisher> log) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var timer = new PeriodicTimer(TimeSpan.FromSeconds(5));
        while (await timer.WaitForNextTickAsync(stoppingToken)) { /* publish pending messages */ }
    }
}

BackgroundService implements IHostedService's start/stop lifecycle and cancellation once; subclasses supply only ExecuteAsync. Same for DelegatingHandler, JsonConverter<T>, AuthenticationHandler<T>, ControllerBase. These bases are designed for extension: small, documented hooks, the base controls the flow (template method), and subtypes are fully substitutable.

In domain code, a small closed hierarchy of results or events (PaymentResult.Approved/Declined) or a family of value types with shared invariants can also be appropriate — often as sealed records with a private base constructor.

3. Signs a hierarchy has gone wrong

• Combinatorial explosion: PdfEmailReport, PdfSftpReport, CsvEmailReport...
• Subclasses that override to do nothing or throw (NotSupportedException) — Liskov violations.
• Deep hierarchies where behaviour requires reading 4–5 classes.
• Base classes full of protected helpers used by some subclasses, with flags like if (this is SpecialImporter).
• "BaseService"/"BaseRepository" inherited just for logging or helpers.
• Changes to the base routinely break subclasses.
• Mocking pain: tests subclass production classes to override pieces.

4. How I'd refactor a hierarchy that's gone wrong

Incrementally, with tests as a safety net:

1. Characterisation tests around the current behaviour of each subclass (approval/snapshot tests are useful for reports).
2. Identify the axes of variation — e.g. data source, format, delivery.
3. Extract each axis into an interface (IReportQuery, IReportFormatter, IReportDelivery), implementing them by moving code out of subclasses.
4. Make the base class delegate to those strategies (it becomes a composition root for the workflow), so existing subclasses keep working while you migrate.
5. Replace subclasses with configuration: a report definition composed of strategies, registered in DI (keyed services work well).
6. Delete the hierarchy once no subclasses remain; seal the new classes.
7. Watch for behaviour that relied on override order or protected state — that's where bugs hide; tests catch it.

This is the "Replace Inheritance with Delegation" and "Replace Subclass with Strategy" refactorings (Fowler).

5. A production example (how I'd tell it)

[In my case] a reporting service had a hierarchy of [~35] report classes combining format and delivery channel; adding SharePoint delivery meant touching [a dozen] classes. I added snapshot tests for each report's output, extracted formatter and delivery strategies, made the base class delegate to them, then migrated reports to a definition table one by one over [a few sprints]. New channels became one class and a registration, and the base class disappeared.