Java: fill the gaps

Pattern matching: зачем?



Последние годы в джаву активно добавляется группа фич на тему pattern matching.



Тагир Валеев из Intellij IDEA в этом докладе рассказывает, какие это сложные фичи, как много челленджей стояло перед командой разработки. Но не говорит, зачем он вообще нужен.



Архитектор java Brian Goetz пишет, что pattern matching — не просто синтаксический сахар, а движение в сторону data oriented programming. Но это слабо применимо к большинству корпоративных систем, где доминирует ООП и изредка встречается функциональное программирование.



Большая часть моих знакомых считает паттерн матчинг "стрелкой вместо двоеточия в свиче":)



Так что сегодня расскажу, для каких задач пригодится pattern matching. В следующем посте обсудим реализацию в java.



Формат входных данных в энтерпрайзе обычно чётко определён. Если входящее сообщение не подходит по формату — это ошибка со стороны клиента.



Но бывает, что система работает со множеством источников данных, и выделить общий формат очень сложно.



Например, вы парсите чужие сайты/документы/дампы и достаёте оттуда что-то полезное. Знаю один проект, где бизнес-данные вытаскивают из логов(!) другой системы🤯



В итоге входные данные выглядят как [Object, Object, Object].



Паттерн — схема того, что мы ищем. Паттерн для поиска координат может выглядеть так:



▫️ [Double, Double] — ищём массив из двух чисел с плавающей запятой

▫️ [(-90;90), (-180,180)] — массив с двумя числами в указанных диапазонах



Дальше идём по набору данных и проверяем их на соответствие паттерну.



Традиционно для такой задачи используется связка if + instanceOf. Вариант рабочий, но читаемость ужасная.



Вот что нужно написать, чтобы проверить, является ли координатами массив [Object, Object] data:

if (data.length == 2 && data[0] instanceOf Double && data[1] instanceOf Double) {

   double n = (Double) data[0];

   double e = (Double) data[1];

   if (n ≥ -90 && n≤ 90 && e ≥ -180 && e ≤ 180) { 

      // что-то делаем 

   }

}

В pattern matching многие проверки убираются под капот, и код выглядит симпатичнее:

switch(data) {

   case [(-90; 90), (-180, 180)]:  

        // что-то делаем

}

Близкий родственник паттерн матчинга — регулярные выражения. Строка — это набор символов, внутри этого набора ищутся паттерны. Можно сделать ту же работу через if, но регулярка удобнее. Плюс в строке элементы однородные (символы), а паттерн матчинг работает с разными типами данных.



Ещё пример:

double discount = switch(transaction) {

   case ["vip", Long, _, _, Double sum] → sum*0,9

   case _ → 0

}

Здесь ищем список из 5 элементов, где первый — строка "vip", второй и пятый — число. Если нашли — можно сразу работать с полем sum. Если не нашли — используем паттерн по умолчанию _



С if-ами эта конструкция будет гораздо объёмнее



Резюме



✅ Pattern matching нужен, когда мы пытаемся найти что-то знакомое в слабо- или неструктурированных данных.

✅ Большинство instanceOf и if отправляются под капот, и мы получаем более компактный код.

✅ Разумеется, применить pattern matching можно и в других сценариях, но здесь видится наибольший профит в корпоративном царстве ООП.



В следующем посте распишу возможности pattern matching конкретно в джаве.

Спойлер: пока не впечатляет😑