🔮 Pattern Matching в Switch: Типизируй это!

Помните этот бесконечный кошмар, когда вам приходит Object, и нужно понять, что внутри?
Раньше мы писали "лестницу" из if-else и instanceof с кучей ручного кастинга (приведения типов).

❌ Было (Боль и слезы):

Object obj = getUnknownObject();

if (obj instanceof String) {
    String s = (String) obj; // Ручной каст
    System.out.println("Строка: " + s.length());
} else if (obj instanceof Integer) {
    Integer i = (Integer) obj; // Опять каст
    System.out.println("Число: " + i);
} else if (obj instanceof Long) {
    // ... и так до бесконечности
}

✅ Стало (Java 21 LTS):
Теперь switch умеет проверять типы! Больше никаких instanceof и ручных приведений. Переменная создается прямо в кейсе.

switch (obj) {
    case String s  -> System.out.println("Строка: " + s.length());
    case Integer i -> System.out.println("Число: " + i);
    case Long l    -> System.out.println("Длинное число: " + l);
    default        -> System.out.println("Непонятно что");
}

🛡 Guarded Patterns (Охрана в кейсах)

Но это еще не всё. Часто бывает, что тип нам подходит, но нужно проверить еще и значение.
Раньше пришлось бы ставить if внутри case. Теперь у нас есть ключевое слово when.

switch (obj) {
    // Попадет сюда, ТОЛЬКО если это строка И она длиннее 10 символов
    case String s when s.length() > 10 -> 
        System.out.println("Длинная строка: " + s);
        
    // Любая другая строка
    case String s -> 
        System.out.println("Короткая строка: " + s);
        
    case Integer i -> 
        System.out.println("Число: " + i);
        
    default -> {}
}

👻 А как же Null?

В старом switch, если передать null, мы мгновенно получали NullPointerException.
В новом switch можно (и нужно!) обрабатывать null легально:

switch (obj) {
    case String s -> System.out.println("Это строка");
    case null     -> System.out.println("Пришел null!"); // Никакого NPE
    default       -> System.out.println("Что-то другое");
}

⚡Это не просто "сахар". Это изменение подхода к полиморфизму.
Если раньше логика часто размазывалась по методам классов (animal.makeSound()), то теперь можно собирать логику обработки разных типов в одном месте, что часто бывает удобнее при написании бизнес-логики (например, обработка разных типов ивентов или DTO).

🔥 Итог

🔴Switch теперь принимает любые объекты.
🔴Кастинг происходит автоматически (case String s).
🔴Можно уточнять условия через when.
🔴Можно безопасно ловить null.

#PatternMatching #NewJava #CleanCode

📲 Мы в MAX

👉@BookJava

🎯 Открытый урок «Сетевой чат на C#».

🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».

На вебинаре:
✔️ Рассмотрим написание сетевого приложения на C#.
✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов.
✔️Также затронем темы многопточности и асинхронности

Кому будет полезно:
- Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании.

Что вы получите:
- По итогам вебинара смогут проектировать сетевые приложения.
- Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях.
- На практике попробуют разработать такое приложение.

🔗 Ссылка на регистрацию: https://vk.cc/cTqyyY

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔒 Sealed Classes: Архитектурный фейсконтроль

В ООП всегда была проблема с наследованием. Либо ваш класс открыт для всех («Наследуйся кто хочет!»), либо он закрыт наглухо (final).
Но что, если я хочу, чтобы мой класс Shape (Фигура) могли наследовать только Circle и Square, и больше никто?

Раньше это решалось костылями (пакетная видимость, скрытые конструкторы). В Java 17 появился официальный механизм: Sealed Classes.

🚧 Как это работает?

Вы помечаете класс (или интерфейс) ключевым словом sealed и после слова permits перечисляете тех, кому "можно".

// Родитель: Разрешает наследование ТОЛЬКО этим двум классам
public sealed interface Payment 
    permits CreditCard, Cash { 
}

Теперь, если Вася из соседнего отдела попытается написать class Crypto extends Payment, компилятор ударит его по рукам. 🚫

🚦 Правило трех дорог

Наследники запечатанного класса обязаны выбрать свою судьбу. Они должны иметь один из трех модификаторов:

1. final - Цепочка наследования обрывается. Дальше наследовать нельзя.

public final class Cash implements Payment { ... }

2. sealed - Иерархия продолжается, но снова под контролем.

public sealed class CreditCard implements Payment permits Visa, MasterCard { ... }

3. non-sealed - "Открываем шлюзы". Дальше от этого класса может наследоваться кто угодно (возврат к старому поведению Java).

public non-sealed class DebitCard implements Payment { ... }

🧩 Главная фишка: Комбо со Switch

Зачем это нужно, кроме запретов? Ради безопасности.
Когда вы используете sealed иерархию в новом switch, компилятор знает все возможные варианты.

Вам больше не нужно писать ветку default!

// Метод обработки платежа
String process(Payment p) {
    return switch (p) {
        case CreditCard c -> "Processing card: " + c.getNumber();
        case Cash c       -> "Processing cash amount: " + c.getAmount();
        // default НЕ НУЖЕН! Компилятор знает, что третьго не дано.
    };
}

Если завтра вы добавите в permits новый класс Crypto, код перестанет компилироваться, пока вы не обработаете этот новый кейс в свитче.
Это спасает от багов, когда в бизнес-логику добавили новый тип, а обработчики обновить забыли.

🔥 Итог

Sealed Classes + Records + Switch Pattern Matching = 💎
Это "Святая Троица" современной Java. Используйте запечатанные классы для моделирования доменной области, где количество вариантов конечно и известно заранее (статусы заказа, типы платежей, виды пользователей).

#Java17 #SealedClasses #Architecture #CleanCode

📲 Мы в MAX

👉@BookJava