🔒 Java Sealed Classes: Диктатура в вашей иерархии
Раньше в Java у нас было всего два стула для классов:
1. Public: Наследуйся кто хочет (открытый проходной двор).
2. Final: Никто не пройдет (полная изоляция).
Но что, если я хочу разрешить наследование только моим классам Circle и Square, но запретить Васе из соседнего отдела создавать свой кривой Triangle?
Начиная с Java 17, у нас есть Sealed Classes.
🚧 Как это работает?
Вы используете ключевое слово sealed и permits, чтобы явно перечислить, кому дозволено быть вашим наследником.
public sealed interface PaymentResult
permits Success, Failure, Pending {
}
Теперь компилятор гарантирует: в мире существуют только три вида PaymentResult. Четвертого не дано.
🤝 Идеальная пара: Sealed + Records
Чаще всего наследниками делают record, потому что они идеально подходят для хранения данных.
public record Success(String txId) implements PaymentResult {}
public record Failure(String error) implements PaymentResult {}
public record Pending(long timestamp) implements PaymentResult {}
🧠 Главная фишка: Умный Switch (Pattern Matching)
Зачем нам эти ограничения? Ради исчерпываемости (Exhaustiveness).
Когда вы используете sealed классы в новых switch (Java 21+), компилятор знает все возможные варианты.
Вам не нужно писать default ветку!
String message = switch (result) {
case Success s -> "Paid! ID: " + s.txId();
case Failure f -> "Error: " + f.error();
case Pending p -> "Wait...";
// Нет default! И это безопасно.
};
В чем магия? Если через полгода вы добавите в permits новый вариант Cancelled, ваш код перестанет компилироваться везде, где используется этот switch. Компилятор ткнет вас носом: "Ты забыл обработать новый статус!". Это спасает от сотен багов в сложной бизнес-логике.
📜 Три правила для наследников
Наследник sealed класса обязан выбрать одну из трех стратегий:
1. final: На мне иерархия заканчивается (как в Records).
2. sealed: Я продолжаю жесткий контроль, вот мои наследники.
3. non-sealed: Я открываю шлюзы - от меня может наследоваться кто угодно (возврат к старому поведению).
🚀 Итог: Используйте Sealed Classes, когда ваша модель данных представляет собой конечное множество вариантов:
-Статусы заказа
-Типы пользователей (Admin, User, Guest)
-Результаты операций (Success, Error)
Это делает код предсказуемым и безопасным на уровне компилятора.
#Java17 #Architecture #CleanCode #PatternMatching
Раньше в Java у нас было всего два стула для классов:
1. Public: Наследуйся кто хочет (открытый проходной двор).
2. Final: Никто не пройдет (полная изоляция).
Но что, если я хочу разрешить наследование только моим классам Circle и Square, но запретить Васе из соседнего отдела создавать свой кривой Triangle?
Начиная с Java 17, у нас есть Sealed Classes.
🚧 Как это работает?
Вы используете ключевое слово sealed и permits, чтобы явно перечислить, кому дозволено быть вашим наследником.
public sealed interface PaymentResult
permits Success, Failure, Pending {
}
Теперь компилятор гарантирует: в мире существуют только три вида PaymentResult. Четвертого не дано.
🤝 Идеальная пара: Sealed + Records
Чаще всего наследниками делают record, потому что они идеально подходят для хранения данных.
public record Success(String txId) implements PaymentResult {}
public record Failure(String error) implements PaymentResult {}
public record Pending(long timestamp) implements PaymentResult {}
🧠 Главная фишка: Умный Switch (Pattern Matching)
Зачем нам эти ограничения? Ради исчерпываемости (Exhaustiveness).
Когда вы используете sealed классы в новых switch (Java 21+), компилятор знает все возможные варианты.
Вам не нужно писать default ветку!
String message = switch (result) {
case Success s -> "Paid! ID: " + s.txId();
case Failure f -> "Error: " + f.error();
case Pending p -> "Wait...";
// Нет default! И это безопасно.
};
В чем магия? Если через полгода вы добавите в permits новый вариант Cancelled, ваш код перестанет компилироваться везде, где используется этот switch. Компилятор ткнет вас носом: "Ты забыл обработать новый статус!". Это спасает от сотен багов в сложной бизнес-логике.
📜 Три правила для наследников
Наследник sealed класса обязан выбрать одну из трех стратегий:
1. final: На мне иерархия заканчивается (как в Records).
2. sealed: Я продолжаю жесткий контроль, вот мои наследники.
3. non-sealed: Я открываю шлюзы - от меня может наследоваться кто угодно (возврат к старому поведению).
🚀 Итог: Используйте Sealed Classes, когда ваша модель данных представляет собой конечное множество вариантов:
-Статусы заказа
-Типы пользователей (Admin, User, Guest)
-Результаты операций (Success, Error)
Это делает код предсказуемым и безопасным на уровне компилятора.
#Java17 #Architecture #CleanCode #PatternMatching