Еще одна статья про реактивное программирование. И только не надо на этой строчке закатывать глаза и томным голосом говорить вслух — "Ну что еще ты можешь мне рассказать про реактивное программирование… а?". Она немного отличается от кучи других, написаных словно под копирку, поэтому некоторые вещи в ней могут показаться… странными или даже совершенно неуместными, как сортирный юмор. Совершенно не важно, знаешь ли ты наизусть reactive manifesto, присутствует ли в твоем утреннем кофе бекпрешур, трогаешь ли ты вот этими вот своими ручками всякие паблишеры и сабскрайберы или пишешь старый добрый синхронный, блокирующийся код. А может быть только недавно, кто-то своим откровенно рекламным докладом про светлое будущее и потоковый оргазм (ну или струйный, тут тонкости перевода решают все), от использования одной из реактивных библиотек конечно-же, зажег в твоих глазах интерес к новой технологии. Будет интересно. И так, представим, что мы совсем сошли с ума… Хотя слово представим здесь больше для политкорректности, потому что все, кто знает автора, в курсе того, что он сидит целыми днями в запертой квартире. Работает по ночам, выкуривает по три кальяна в день, и пару раз в неделю выходит на улицу. Обычно это происходит ради встречи со своим психотерапевтом, но иногда причина совсем другая — IKEA. И так, мы берем старый синхронный, но работающий код: И пытаемся его отрефакторить, потому что нам кажется… Хотя нет, это слишком, никто же не будет так делать в здравом уме. Никто. В здравом уме. Но как вы уже могли заметить, я это сделяль. И прошу заметить! Я сдержал себя от того, чтобы использовать в этом примере пару микросервисов, один для сложения, а другой для умножения, с которыми пришлось бы общаться через rSocket и kafka.  Кстати, это была разминка. Прежде чем мы начнем, я хотел бы дать два совета. И так, совет первый: будь всегда готов к тому, что твои коллеги могут быть реально больными психопатами с кучей детских комплексов, которые будут выплескиваться в виде кода, не самого лучшего качества, и весьма изящных архитектурных решений. Совет второй. Его я решил оставить в конце статьи. Но если после всего увиденного ты решишь, что тебе стоит держаться подальше от этого д%&@а, то ты знаешь где его искать. Возьмем чуть более реальный пример. Например… деревья. Почему именно они? Потому что все мы любим деревья и как объект в реальной жизни и как структуру данных. Это одна из важнейших частей окружающего нас мира. Деревья вырабатывают кислород, чтобы мы могли дышать.  Многие животные живут на деревьях, или в местах скоплениях этих объектов (эти места называются парк или лес, в зависимости), да что животные, даже бомжи и те живут в картонных коробках, которые изначально были деревьями.  Кстати интересный факт, с древних пор из деревьев человечество добывает один из самых часто используемых материалов в жизнедеятельности человека — древесину. Только представьте, все те палки, что мы вставляем сами себе в колеса всю нашу жизнь, и при этом во всем виним всех остальных, также сделаны из древесины. У нас есть дерево, обычное, ничем не примечательное дерево, которое росло на лужайке нашего кода и мечтало когда-нибудь, когда оно вырастет, превратиться в BST: И в один прекрасный момент, например в понедельник в шесть утра, после бессонной ночи, одному программисту пришла в голову идея сделать его реактивным. И он это сделал. Потому что он человек дела. Чувствуете, как в воздухе повис вопрос — “Зачем?!”. Во-первых это красиво, а во-вторых очень скейлбл, так как асинхронно, также это безопасно для окружающей среды и Грета Тунберг не приедет к нам однажды на поезде с огромным страпоном… вы понимаете о чем я. И не стоит забывать о том, что теперь у нас появился бекпрешур. И кстати, напоминаю, что ни один рефакторинг нельзя проводить без тестового покрытия. Отлично. Начало положено, теперь нам осталось отрефакторить три простых метода invert, sumOfLeftLeaves и searchBST в старом, скучном, синхронном дереве и добавить немного тестов. И так, у нас уже есть реализованный метод invert, но, к сожалению, он не реактивный, посмотрите как уныло он выглядит, единственный плюс этого метода в том, что он легко читаем и не составляет труда понять, что если мы инвертируем дерево, то мы рекурсивно проходимся по всем его нодам, создаем копии и меняем его детей местами. То есть в левый чайлд новой ноды мы кладем инвертированную ноду из правого чайлда и наоборот. И везде эти проверки на null. Посмотрите что произошло, когда мы переписали его, он заиграл новыми красками, и как бонус, мы бесплатно добились null safety. Обычно люди делятся на два типа, тип первый — это те, кто понимают, что будет делать этот метод из его названия, и все остальные люди, которые годами не выходят из своей комнаты и никогда не видели деревьев.  Второму типу людей я могу помочь советом обратиться к своему психотерапевту, который, скорее всего, сможет составить схему лечения. И рассказать смысл этого метода. Нода считается листом leaf, если у нее нет детей, а левой, если она растет у своего родителя из левого указателя left. В названии метода это и написано. Но к чему слова, давайте к делу, посмотри как было... … и как стало Wow! So reactive. Much async. Too awesome. So null safety. Much backpressure. So scalable... Кстати у нас остался еще один метод, в котором, я вам обещаю, всю эту мощь мы направим в нужное русло. Каждое дерево мечтает стать бинарным деревом поиска, а этот метод поможет нам в поиске по нему. Этим все сказано, поэтому сразу показываю как ужасно было, и как прекрасно стало. Просто прочувствуйте это: Больше нечего добавить. Вот это и есть реактивное программирование, оно самое.  Когда делаешь поистине крутые вещи, очень сложно остановиться. Ты устал, глаза закрываются, хочется спать, но внутри себя ты ощущаешь огромный поток мотивации. Ты все делаешь правильно, нельзя останавливаться, лови это чувство, продолжай делать мир лучше.  Поэтому покончив с деревьями, ты, без колебаний, переходишь к старым добрым односвязным спискам. Их время еще не прошло, до сих пор тысячи людей, на технических собеседованиях проверяют их на зацикленность. Пришло время это делать реактивно. Раз уж мы затронули тему технических собеседований, то не стоит и забывать про любимую всеми задачу на проверку вложенности скобок. Show must go on! Wow. So immutable… Much reactive. Кстати, как я и обещал, в конце статьи совет номер два: Знай область применения своей любимой технологии и не старайся решить при помощи неё все существующие проблемы. Иногда это будет выглядеть по меньшей мере глупо и непрактично.