What does sealed mean in C#, and should application classes be sealed by default? Explain sealed classes and sealed overrides, the performance benefits, the effect on testing and mocking, and the versioning rules.

How I would answer this in an interview

sealed on a class means no class can derive from it; sealed override on a member means no further overrides below that point. My view: yes, application classes should be sealed by default and unsealed only when you deliberately design for inheritance. I'd justify it with design, performance, testing and versioning arguments.

1. Sealed classes and sealed overrides

public sealed class OrderService(IOrderRepository repo) { ... }   // can't be inherited

public class Report
{
    public virtual string Render() => "...";
}
public class SalesReport : Report
{
    public sealed override string Render() => "...";   // subclasses of SalesReport can't override Render
}

Static classes are implicitly sealed (and abstract). Records can be sealed (sealed record), which also simplifies their generated equality. Structs are always sealed.

2. Why seal by default

Design and correctness

• Inheritance is a contract: once someone subclasses your type, every protected and virtual member, and the order in which you call them internally, becomes something you can't freely change (the fragile base class problem).
• A class not designed for inheritance usually doesn't document self-use or invariants for subclasses; subclassing it is fragile.
• Sealing communicates intent: "use me, compose me, don't extend me".
• Unsealing later is non-breaking; sealing later is breaking. So the safe default is sealed.

Performance

• The JIT can devirtualise calls on sealed types: virtual calls (including ToString, Equals, interface calls) on a variable of a sealed type become direct calls that can be inlined.
• Type checks and casts are cheaper: obj is SealedType is a single MethodTable comparison, no hierarchy walk.
• Array stores of sealed element types can skip covariance checks.
• The .NET runtime team measured noticeable gains from sealing internal types, and analyser CA1852 ("Seal internal types") was added in .NET 7. Gains are usually small per call but free.

3. Effect on testing and mocking

• Mocking libraries like Moq and NSubstitute create subclasses at run time, so they can't mock sealed classes (or non-virtual members).
• That's fine when you follow good practice: mock interfaces at boundaries (repositories, gateways, clocks), and use real objects for domain classes and services' internal collaborators.
• If you find yourself wanting to mock a sealed concrete class, it's usually a sign that a boundary is missing an interface or the test is too implementation-focused.
• For framework types you don't own (e.g. HttpClient), mock at a different seam (HttpMessageHandler, IHttpClientFactory).

4. Versioning rules

For public library types, sealing is a stronger commitment: you can unseal later without breaking anyone, but you can't seal once published without a major version. For application code where you own all callers, sealing is pure benefit — you can unseal any time you actually need inheritance.

5. When not to seal

• Types designed as extension points (ControllerBase, BackgroundService, DelegatingHandler, your own abstract templates).
• Types where frameworks need to create proxies (EF Core lazy-loading proxies and change-tracking proxies require non-sealed entities with virtual navigations; Castle DynamicProxy-based interceptors also need non-sealed types).
• Base classes in a deliberate hierarchy.

6. A production example

We enabled CA1852 as a warning across a large solution, sealed ~600 internal classes in one pull request (mostly mechanical with dotnet format), and saw a small but measurable throughput improvement in a CPU-heavy pricing service (a few percent, from devirtualised Equals/GetHashCode calls in dictionary-heavy code). The bigger win was design clarity: a couple of builds failed because tests were subclassing services to override methods — which exposed missing interfaces at real boundaries that we then fixed.