Implementing Sealed Classes in Java

Implementing sealed classes well is mostly about choosing the right closure boundary. The syntax is straightforward. The design question is whether the domain is truly finite enough to justify sealing the hierarchy.

A Typical Shape

1public sealed interface OrderState
2        permits Draft, Submitted, Fulfilled, Cancelled {}
3
4public record Draft(UUID id) implements OrderState {}
5public record Submitted(UUID id, Instant submittedAt) implements OrderState {}
6public record Fulfilled(UUID id, Instant fulfilledAt) implements OrderState {}
7public record Cancelled(UUID id, String reason) implements OrderState {}

This works well because:

• the states are explicit
• each state can carry state-specific data
• callers can reason about a fixed set of variants

Prefer Domain Boundaries, Not Technical Ones

Do not seal a hierarchy merely because the current codebase happens to have four implementations. Seal it when the business concept itself is closed.

That usually means:

• a fixed workflow
• a closed protocol
• a result type with bounded variants

If external extension is part of the design, sealing is the wrong move.

Combine Sealed Types With Records Carefully

Sealed interfaces paired with records are often excellent for lightweight algebraic-style modeling:

1public sealed interface LoginOutcome
2        permits LoginOutcome.Allowed, LoginOutcome.Blocked {
3
4    record Allowed(UUID userId) implements LoginOutcome {}
5    record Blocked(String reason) implements LoginOutcome {}
6}

This model is compact, immutable, and easy to branch on. It is one of the clearest examples of how modern Java can express data-oriented domain variants.

Common Mistakes

• Sealing hierarchies that actually need extension.
• Creating a sealed hierarchy and then duplicating variant logic in many if chains anyway.
• Packing unrelated variants into one root type just because the syntax makes it easy.
• Treating sealed classes as a replacement for all polymorphism.

Practical Rule

Implement sealed hierarchies when the domain truly has a bounded set of legal forms. Keep the root type small, the variants meaningful, and the closure boundary tied to business truth rather than convenience.