Комментарии 19
Мне это больше всего напоминает enum. Только в enum речь идет о экземплярах, а тут о классах.
Во-первых, enum - константа. Во-вторых, enum , в отличие от класса, никак нельзя параметризовать. Т.е. sealed interface Value<T> можно, а enum Value<T> - нельзя.
То же возникла эта мысль. Особенно на enum из Rust похоже. Вот простой пример:
https://doc.rust-lang.org/std/option/enum.Option.htmlpub enum Option<T> {
None,
Some(T),
}
В sealed классе это наверное было бы типа:
public sealed class Option<T> permits None, Some..
public final class None extends Option..
public final class Some<T> extends Option..
Те типа enum, но который может нести состояние. И тогда тут все фишки enum работают, но можно ещё дополнительно состояния использовать.
Оно и есть, по существу. Мне около полугода назад на реддите один из авторов JVM (вроде как) и доказывал, что основное применение и идея Sealed - создание тип сумм, что отражено в JEP.
Если у кого есть примеры практического применения, где прямо нужно, - поделитесь, пожалуйста.
паттерн матчинг в свитч контсрукциях, когда число наследников заранее известно
Таким образом мы гарантируем, что свитч покрывает всё варианты? Но в какой-то момент придётся расшириться и гарантия уйдёт, не?
Классический пример - парсер json. Значением (JsonValue) может быть null, число, строка, массив, объект. Соответственно, расширять JsonValue , кроме как обозначенным типам, незачем.
Когда в библиотеках нужно запретить наследование для пользователя, но самим активно наследоваться. В jooq активно используется.
Кроме паттерн матчинга, например, в вашей библиотеке есть final класс, вы хотите добавить похожий класс, но вынести в родительский класс общую часть, без sealed от родителя могли бы наследоваться и пользователи вашей библиотеки, чего вы хотите избежать.
Очевидно, любой public класс хочет чтобы его максимально использовали, наследовали код, создавали экземпляры - поэтому у него должно быть много конструкторов. Sealed класс это какой-то шаг назад - давайте напишем класс, который не будем использовать. Не делайте его тогда public, делов-то. Какое-то изменение языка ради изменения языка, только для того чтобы команда Java зарплату получала. Иных причин у этого изменения нет
Не так уж и очевидно. Во-первых, final классы, от которых вообще нельзя наследоваться, существуют давно. При этом они вполне публичные, например String. Во-вторых, класс желательно проектировать так, чтобы от него было удобно наследоваться, например не вызывать переопредяемые методы в конструкторах, иначе можно получить спецэффекты. В третьих, решение сделать некий класс непубличным, а его наследники финальными и публичными не всегда удобно, т.к. лишает нас возможности использовать полиморфизм.
Не, чтоб соответствовать высоким стандартам других языков )))
любой public класс хочет чтобы его максимально использовали
Угу, именно поэтому во многих фреймворках и библиотеках присутствует пакет internal.
Package private не спасает от наследования: в своем super.puper.project делаем пакет com.google.xxx и наследуем. Для меня как sealed classes выглядят как enum в для классов,как написал выше @serarhi . Одно из преимуществ в том что не надо придумывать поведение default для несуществующих кейсов Pattern Matching for switch and Sealed Classes
Sealed классы Java в действии: создание надежных и безопасных приложений