Краткий ответ

Sealed-класс разрешает прямое наследование только от заранее объявленных типов. Эти типы перечисляются в permits либо выводятся компилятором, если все наследники находятся в том же исходном файле. Каждый разрешённый наследник обязан быть объявлен как final, sealed или non-sealed.

Исторический контекст

Обычное наследование в Java открыто: любой доступный класс может расширить базовый класс, если тот не объявлен final. Это удобно для расширения, но затрудняет контроль архитектуры и статический анализ закрытых иерархий.

Sealed-типы появились для явного описания ограниченной иерархии. Такой подход особенно полезен для моделей с фиксированным набором вариантов и для проверок исчерпывающего разбора в современных конструкциях switch.

Постановка проблемы

Если базовый тип допускает неограниченное наследование, библиотека не может надёжно знать полный набор его вариантов. Это увеличивает риск появления неподдержанных реализаций, нарушающих инварианты модели.

sealed решает эту проблему на уровне компиляции: попытка создать прямого наследника, не указанного в разрешённом списке, становится ошибкой. Ограничение касается именно прямых наследников; дальнейшая иерархия определяется модификатором разрешённого наследника.

Подробное решение

У sealed-класса или sealed-интерфейса есть закрытый набор непосредственных наследников. Он задаётся предложением permits, если список нельзя вывести из объявления типов в том же исходном файле.

sealed interface Payment permits CardPayment, CashPayment {}

final class CardPayment implements Payment {}
non-sealed class CashPayment implements Payment {}

class CryptoPayment implements Payment {} // ошибка компиляции

CardPayment закрывает ветвь: от него нельзя наследоваться. CashPayment открывает свою ветвь с помощью non-sealed, поэтому его наследники уже не ограничиваются исходным списком Payment.

Вместо final наследник может быть sealed, чтобы задать собственный ограниченный набор прямых наследников. Модификатор non-sealed явно снимает ограничение для конкретной ветви.

Для корректной иерархии разрешённые прямые наследники должны находиться в том же именованном модуле, что и sealed-тип, либо в том же пакете, если используется неназванный модуль. Каждый такой наследник обязан выбрать один из трёх вариантов продолжения иерархии: запретить дальнейшее наследование через final, продолжить ограничения через sealed или открыть ветвь через non-sealed.

sealed не меняет обычную динамическую диспетчеризацию методов. Переопределение и выбор реализации экземплярного метода по-прежнему зависят от фактического класса объекта; sealed-ограничение лишь делает множество возможных классов контролируемым компилятором.

Главный компромисс — меньшая расширяемость. Это хорошо для доменной модели и API с заранее определёнными вариантами, но плохо для библиотек, которые должны позволять сторонним клиентам свободно добавлять реализации.

Ситуация из практики

Команда моделирует результат операции как иерархию Payment. Требование бизнеса допускает только оплату картой и наличными, поэтому открытый интерфейс был бы рискован: другой модуль мог бы добавить несовместимый способ оплаты.

Рассматривались два варианта. final на отдельных классах полностью закрывает каждую ветвь, но не выражает централизованный список допустимых вариантов. Обычный интерфейс сохраняет расширяемость, однако не позволяет компилятору проверить, что обработаны все предусмотренные виды оплаты.

Выбран sealed interface Payment с двумя разрешёнными реализациями. Карточная оплата объявлена final, поскольку у неё нет вариантов специализации, а наличная — non-sealed, поскольку для неё допускаются дополнительные внутренние виды. В результате основная модель защищена от случайных реализаций, а расширение разрешено только там, где оно действительно требуется.

Что кандидаты часто упускают

1. Достаточно ли объявить базовый тип sealed, чтобы полностью закрыть всю иерархию?

Нет. sealed ограничивает только непосредственных наследников. Если один из них объявлен non-sealed, его ветвь снова становится открытой. Если наследник объявлен sealed, ограничения продолжаются по его собственному списку permits.

2. Можно ли разрешённому наследнику остаться обычным классом без специального модификатора?

Нет. Непосредственный наследник sealed-типа должен быть final, sealed или non-sealed. Это заставляет разработчика явно выбрать судьбу ветви и предотвращает неявное открытие или неоднозначность архитектуры.

3. Чем sealed отличается от final применительно к проектированию API?

final запрещает любое наследование от конкретного класса. sealed разрешает заранее перечисленные варианты и может передавать контроль дальше по иерархии через другие sealed-типы. Поэтому final подходит для полного запрета расширения, а sealed — для закрытой, но структурированной иерархии.