Sealed classes in Java are a game-changer for creating robust type hierarchies. They give us the power to define a closed set of subtypes, which is super useful for modeling specific domains or creating APIs that guide users toward correct usage.

Let’s start with the basics. A sealed class is declared using the ‘sealed’ modifier, followed by a ‘permits’ clause that lists all allowed subtypes. Here’s a simple example:

public sealed class Shape permits Circle, Rectangle, Triangle {
    // Common shape methods and properties
}

public final class Circle extends Shape {
    // Circle-specific implementation
}

public final class Rectangle extends Shape {
    // Rectangle-specific implementation
}

public final class Triangle extends Shape {
    // Triangle-specific implementation
}

In this setup, we’ve defined a sealed class ‘Shape’ that only allows three subtypes: Circle, Rectangle, and Triangle. No other classes can extend Shape, giving us tight control over our type hierarchy.

One of the coolest things about sealed classes is how well they play with pattern matching. Check this out:

public double calculateArea(Shape shape) {
    return switch (shape) {
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.width() * r.height();
        case Triangle t -> 0.5 * t.base() * t.height();
    };
}

This switch expression is exhaustive - we’ve covered all possible subtypes of Shape. If we later add a new subtype to Shape, the compiler will remind us to update this method. It’s a great way to catch errors early and keep our code in sync with our class hierarchy.

Sealed classes aren’t just about restriction, though. They’re about intentional design. When you use a sealed class, you’re saying, “These are the only types that make sense in this context.” It’s a form of documentation that’s enforced by the compiler.

Let’s dive a bit deeper with a more complex example. Imagine we’re modeling a simple banking system:

public sealed interface Account permits CheckingAccount, SavingsAccount, CreditCardAccount {
    String getAccountNumber();
    double getBalance();
}

public final class CheckingAccount implements Account {
    // Implementation
}

public final class SavingsAccount implements Account {
    // Implementation
}

public non-sealed class CreditCardAccount implements Account {
    // Implementation
}

Here, we’ve used a sealed interface instead of a class. The ‘permits’ clause works the same way. Notice that CreditCardAccount is declared as ‘non-sealed’. This means it can be extended further, giving us flexibility where we need it.

We can combine sealed classes with records for even more concise and expressive code:

public sealed interface Transaction permits Deposit, Withdrawal {
    Account getAccount();
    double getAmount();
}

public record Deposit(Account account, double amount) implements Transaction {}
public record Withdrawal(Account account, double amount) implements Transaction {}

public void processTransaction(Transaction t) {
    switch (t) {
        case Deposit d -> handleDeposit(d);
        case Withdrawal w -> handleWithdrawal(w);
    }
}

This code is clean, self-documenting, and type-safe. The compiler ensures we handle all types of transactions, and the record syntax keeps our value objects concise.

One thing to keep in mind is that all permitted subclasses must be in the same module as the sealed class or interface. If you’re working across module boundaries, you’ll need to use ‘open’ modules or declare your classes as ‘non-sealed’.

Sealed classes aren’t just for simple hierarchies. They can model complex relationships too. Let’s look at a more advanced example:

public sealed interface Expression 
    permits Literal, Variable, BinaryOperation, UnaryOperation {}

public record Literal(double value) implements Expression {}
public record Variable(String name) implements Expression {}

public sealed interface BinaryOperation extends Expression 
    permits Addition, Subtraction, Multiplication, Division {}

public record Addition(Expression left, Expression right) implements BinaryOperation {}
public record Subtraction(Expression left, Expression right) implements BinaryOperation {}
public record Multiplication(Expression left, Expression right) implements BinaryOperation {}
public record Division(Expression left, Expression right) implements BinaryOperation {}

public sealed interface UnaryOperation extends Expression
    permits Negation, Absolute {}

public record Negation(Expression operand) implements UnaryOperation {}
public record Absolute(Expression operand) implements UnaryOperation {}

This hierarchy models mathematical expressions. The sealed interfaces ensure that we can only create valid expression types, while the records provide compact representations of each expression type.

We can then create an interpreter for these expressions:

public class Interpreter {
    private Map<String, Double> variables = new HashMap<>();

    public double evaluate(Expression e) {
        return switch (e) {
            case Literal l -> l.value();
            case Variable v -> variables.getOrDefault(v.name(), 0.0);
            case Addition a -> evaluate(a.left()) + evaluate(a.right());
            case Subtraction s -> evaluate(s.left()) - evaluate(s.right());
            case Multiplication m -> evaluate(m.left()) * evaluate(m.right());
            case Division d -> evaluate(d.left()) / evaluate(d.right());
            case Negation n -> -evaluate(n.operand());
            case Absolute a -> Math.abs(evaluate(a.operand()));
        };
    }

    public void setVariable(String name, double value) {
        variables.put(name, value);
    }
}

This interpreter is concise, readable, and exhaustive. If we add a new type of expression, the compiler will tell us to update our evaluate method.

Sealed classes aren’t just about controlling hierarchies - they’re about creating clear, intentional designs. They help us catch errors at compile-time, write more expressive code, and create APIs that guide users towards correct usage.

As we wrap up, remember that sealed classes are a tool, not a rule. Use them where they make sense in your design. They’re great for modeling closed sets of options, creating extensible-but-controlled APIs, and ensuring exhaustive handling of cases.

In the end, mastering sealed classes is about more than just syntax. It’s about thinking carefully about your type hierarchies, considering what should be open for extension and what should be closed, and using Java’s type system to express your design intentions clearly.

So go ahead, start experimenting with sealed classes in your projects. You’ll likely find they lead you to cleaner, safer, more expressive code. And isn’t that what we’re all aiming for?