Not every class is meant to be a base class. Sealing one is how you say so — on purpose, in writing, enforced by the compiler.

Notice something about nearly every concrete class in lessons 072 and 073's examples — StandardCarrierProcessor, ExpressCarrierProcessor, EmailChannel, SmsChannel. They were all marked sealed, without much comment. That wasn't an accident, and it wasn't just style. It was a deliberate design decision this lesson finally explains:

public sealed class StandardCarrierProcessor : ShipmentProcessor
{
    // ...
}

// Six months later, someone under deadline pressure tries this:
public class ExpediteHackProcessor : StandardCarrierProcessor   //  compiler error
{
    // "I just need to override CalculateShippingCost for one weird customer..."
}
// CS0509: 'ExpediteHackProcessor': cannot derive from sealed type 'StandardCarrierProcessor'

That compiler error isn't a limitation — it's the entire point. The class's author decided, in advance, that StandardCarrierProcessor is a finished, complete implementation, and that any future variation belongs in a new class implementing the same abstraction, not a hack bolted onto this one. sealed is how that decision gets enforced instead of just hoped for.

In this lesson, you'll learn exactly what sealed class and sealed override do, why sealing is a deliberate design act rather than a defensive reflex, how it helps the JIT compiler generate faster code, and a clear set of guidelines for when to seal and when not to.

What Is a Sealed Class or Member?

sealed applied to a class means no other class may inherit from it. sealed applied to an overriding member (a sealed override) means that particular member cannot be overridden again by any class further down the hierarchy — even though the class itself may still be inheritable.

Both are about the same underlying idea — closing off a specific extension point — but at two different scopes: the whole type, or a single member within an otherwise still-open type.

Why Sealing Is a Deliberate Act, Not a Defensive Reflex

Recall the fragile base class problem from lesson 072: any class open to inheritance is, from that moment on, an extension contract you have to maintain forever. Every public and protected member becomes something a future subclass might depend on in ways you can't predict. Sealing a class is the explicit statement: "I am not offering this as an extension point. This is a finished, self-contained implementation."

This matters because leaving a class unsealed "just in case someone needs to extend it later" isn't actually neutral — it's a real, standing commitment:

• Every public and protected member of an unsealed class is potential API surface for subclasses, whether or not any subclass exists yet.
• Once even one subclass exists in a shipped product, changing the base class's behavior risks the exact fragile base class scenario from lesson 072 — silently.
• "Just in case" extensibility that's never used is pure cost: more surface to reason about, more to document, more to keep behaviorally stable — for zero realized benefit.

Sealing flips the default: a class starts closed, and gets opened to inheritance only when there's a real, deliberate reason to design it as an extension point — exactly the way lesson 072's ShipmentProcessor was designed on purpose, with specific virtual extension points, while its concrete carriers were sealed.

Big Picture — Where Sealing Fits in a Hierarchy

This is the shape most production hierarchies should have: one deliberately open abstraction at the top, and sealed, finished implementations at the leaves. Depth doesn't keep growing "just in case" — a new requirement gets a new sealed sibling class, not a deeper chain.

sealed override — Closing One Extension Point Without Closing the Whole Class

public class ReportExporter
{
    public virtual string GetFileExtension() => "txt";
    public virtual string GetMimeType() => "text/plain";
}

public class CsvReportExporter : ReportExporter
{
    // Sealed: the file extension for CSV is a fixed, well-known fact.
    // No further subclass should ever be allowed to redefine what "CSV" means.
    public sealed override string GetFileExtension() => "csv";

    // NOT sealed: MIME type nuances (e.g. a vendor-specific CSV variant)
    // are plausible enough to leave open.
    public override string GetMimeType() => "text/csv";
}

public class ExcelCompatibleCsvExporter : CsvReportExporter
{
    // public override string GetFileExtension() => "csv-x";  //  compiler error — sealed above
    public override string GetMimeType() => "text/csv; charset=utf-8"; //  still open
}

This is the precision tool version of sealing: CsvReportExporter itself stays open to further inheritance, but one specific fact about it — its file extension — is nailed down permanently. This is exactly the "circuit breaker" mentioned in lesson 072: it stops fragility from propagating past this one point, without shutting down the entire hierarchy.

Simple Example

public sealed class Money(decimal amount, string currencyCode)
{
    public decimal Amount { get; } = amount;
    public string CurrencyCode { get; } = currencyCode;

    public static Money operator +(Money a, Money b)
    {
        if (a.CurrencyCode != b.CurrencyCode)
            throw new InvalidOperationException("Cannot add different currencies.");
        return new Money(a.Amount + b.Amount, a.CurrencyCode);
    }

    public override string ToString() => $"{Amount:N2} {CurrencyCode}";
}

// public class DiscountedMoney : Money { }   //  compiler error — Money is sealed

Code → Meaning → Result: Money represents a precise, well-defined value — an amount plus a currency. There is no meaningful "kind of Money" that should be modeled as a subclass; any variation (a discount, a tax adjustment) is a different value, computed and returned as a new Money, not a new subtype. Sealing it documents that decision and prevents anyone from accidentally building a fragile hierarchy on top of a value type that was never meant to have one.

Real-World Example — A Plugin Architecture with Deliberate Sealing

A reporting engine (echoing lesson 073's composed design) defines an extensible base for exporters, but each concrete exporter that ships with the product is sealed — leaving room only for genuinely new exporters, never quiet mutations of existing ones.

public abstract class ReportExporter
{
    protected readonly ILogger Logger;
    protected ReportExporter(ILogger logger) => Logger = logger;

    // Non-virtual: the export pipeline's shape is fixed for every exporter.
    public byte[] Export(ReportData data)
    {
        Logger.Log($"Exporting report '{data.Title}' as {FormatName}...");
        var bytes = Serialize(data);
        Logger.Log($"Export complete: {bytes.Length} bytes.");
        return bytes;
    }

    protected abstract string FormatName { get; }
    protected abstract byte[] Serialize(ReportData data);
}

public sealed class PdfReportExporter(ILogger logger, IPdfRenderer renderer) : ReportExporter(logger)
{
    protected override string FormatName => "PDF";
    protected override byte[] Serialize(ReportData data) => renderer.Render(data);
    // sealed: PDF rendering is a complete, well-tested implementation.
    // A "custom PDF variant" is a new class implementing ReportExporter directly,
    // not a subclass of this one.
}

public sealed class CsvReportExporter(ILogger logger) : ReportExporter(logger)
{
    protected override string FormatName => "CSV";

    protected override byte[] Serialize(ReportData data)
    {
        var csv = string.Join("\n", data.Rows.Select(r => string.Join(",", r)));
        return System.Text.Encoding.UTF8.GetBytes(csv);
    }
}

Why sealing every leaf class here is the right call:

• The extension point that actually matters — "add a new export format" — is already served perfectly by the abstract ReportExporter base. Nobody needs to subclass CsvReportExporter to add, say, TSV support; they write a new class.
• Sealing prevents a future maintainer from "just tweaking" PdfReportExporter via inheritance instead of understanding and modifying it directly — which keeps exactly one implementation of PDF export in existence, not two subtly different ones.
• Each sealed class is now a complete, closed unit: reviewing it, testing it, and reasoning about it never requires wondering "what if a subclass overrides this?"

Under the Hood — Sealing and JIT Devirtualization

Common Confusion

"sealed means the class can't be changed" — no, it means it can't be inherited from

sealed has nothing to do with mutability, or with whether the class's own source code can be edited. It only affects inheritance: whether another class can appear in an : ClassName position. A sealed class's own methods, fields, and properties behave exactly as declared — sealing purely closes off the one specific relationship of "being a base class for something else."

sealed alone on a class with no base — is it even doing anything?

public sealed class Money { ... }, where Money doesn't inherit from anything else, still does real work: it prevents other classes from inheriting from Money. The keyword's job is always about what can derive from this class, never about what this class itself derives from.

Common Mistakes

Mistake 1 — Sealing a class that was specifically designed to be an extension point

Marking the abstract-style base itself sealed defeats the purpose — abstract and sealed together on the same class is actually a compile error in C#, and even a non-abstract base designed with virtual extension points shouldn't be sealed, or those extension points become meaningless.

Seal the concrete, finished leaves of a hierarchy; leave the deliberately-extensible base classes unsealed.

Mistake 2 — Leaving every class unsealed "by default," out of habit

Never sealing anything means every concrete class in the codebase is silently offering itself as a base class, whether or not that was ever intended — reintroducing the fragile base class risk everywhere, by omission rather than decision.

Default to sealed for concrete classes, and unseal deliberately, the same way you'd deliberately mark a method virtual (lesson 072's Mistake 1) — extension should be an intentional design choice, not an accident of never having typed one extra keyword.

Mistake 3 — Sealing to work around a design problem instead of fixing it

Sealing a class specifically to stop a colleague from subclassing it to "hack in" one extra piece of behavior, without providing any legitimate way to get that behavior in.

If there's a real, recurring need to vary behavior, provide it properly — a constructor parameter, a composed interface (lesson 073), or a genuine virtual extension point — rather than using sealed purely as a lock with no accompanying key.

When to Seal, and When Not To

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can reason about sealing as a deliberate design decision, not just a syntax rule.

You now default to sealed the way a careful engineer does — which sets up interfaces (077) perfectly, since interfaces are how you offer real extensibility without ever risking the fragile base class problem at all.

dotnetmadeeasy.com — Learn C# and .NET, the right way.