Реактивний програмування: поняття, навчання, особливості та поради фахівців. Розбираємося з фреймворком ReactiveX і пишемо в реактивному стилі для Android Реактивний програмування

Я хочу розповісти вам про сучасну дисципліни програмування, що відповідає зростаючим вимогам масштабованості, відмовостійкості і швидкого відгуку, і незамінною як в багатоядерних середовищах так і в хмарні обчислення, а також представити відкритий онлайн-курс по ній, який почнеться за все через кілька днів.

Якщо ви нічого не чули про реактивне програмування, все в порядку. Це стрімко розвивається дисципліна, в якій скомбіновані паралелізм (concurrency) c подієвої орієнтованістю і асинхронних. Реактивність властива будь-якому веб-сервісу і розподіленої системі, і служить ядром багатьох вископроізводітельних систем з великим ступенем паралелізму. Якщо коротко, то автори курсу пропонують розглядати реактивне програмування як природне розширення функціонального програмування (з функціями вищих порядків) на паралельні системи з розподіленим станом, координовані і оркестріруемие асинхронними потоками даних, якими обмінюються активні суб'єкти, або актори.

Більш зрозумілими словами це описується в Реактивному маніфесті, нижче я перекажу основні положення з нього, а повний переклад опублікований на Хабре. Як розповідає вікіпедія, термін реактивне програмування існує досить давно і має практичні застосування різного ступеня екзотичності, але новий поштовх до розвитку і поширення він отримав зовсім недавно, завдяки зусиллям авторів реактивного маніфесту - ініціативній групі з Typesafe Inc. Typesafe відома в середовищі функціонального програмування як компанія, заснована авторами прекрасного мови Scala і революційної паралельної платформи Akka. Зараз вони позиціонують свою компанію як творця першої в світі реактивної платформи, призначеної для розробки нового покоління. Їх платформа дозволяє швидко розробляти складні інтерфейси і надає новий рівень абстракції над паралельними обчисленнями і багатопоточність, зменшуючи властиві їм ризики завдяки гарантовано передбачуваному масштабування. Вона реалізує на практиці ідеї реактивного маніфесту і дозволяє розробнику осмислювати і створювати додатки, що відповідають сучасним запитам.

Ви можете познайомитися з цією платформою і реактивним програмуванням, взявши участь в масовому відкритому онлайн-курсі «Принципи реактивного програмування». Цей курс є продовженням курсу Мартін Одерски «Принципи функціонального програмування на Скала», який набрав більше 100 000 учасників і продемонстрував одну з найвищих в світі ступінь успішного проходження масового відкритого онлайн-курсу його учасниками. Разом з творцем мови Скала новий курс читають Ерік Мейер, який розробляв середу Rx для реактивного програмування под.NET, і Роланд Кун, провідний команду розробки Akka в Typesafe в даний час. Курс розкриває ключові елементи реактивного програмування і показує, як вони застосовуються для конструювання подієво-орієнтованих систем, що володіють масштабованість і відмовостійкість. Навчальний матеріал ілюструється короткими програмами і супроводжується набором завдань, кожне з яких - це програмний проект. У разі успішного виконання всіх завдань учасники отримують сертифікати (зрозуміло, і участь і сертифікати безкоштовні). Курс триває 7 тижнів і починається в цей понеділок, 4 листопада. Докладний план, а також вступне відео доступні на сторінці курсу: https://www.coursera.org/course/reactive.

Тим хто зацікавився, або сумнівається, пропоную стислий виклад базових концепцій реактивного маніфесту. Його автори відзначають значні зміни у вимогах до додатків за останні роки. Сьогодні додатки розгортаються в будь-якому оточенні від мобільних пристроїв до хмарних кластерів з тисячами багатоядерних процесорів. Ці оточення висувають нові вимоги до програмного забезпечення та технологій. В архітектурі попереднього покоління акцент робився на керовані сервера і контейнери, а масштабування досягалося за рахунок додаткового дорогого обладнання, пропрієтарних рішень і паралельних обчислень через багатопоточність. Зараз розвивається нова архітектура, в якій можна виділити чотири найважливіші риси, все більше переважають як в призначених для користувача, так і в корпоративних промислових середовищах. Системи з такою архітектурою: подієво-орієнтовані (Event-driven), масштабуються (Scalable), відмовостійкості (Resilient) і мають швидкий відгуком, тобто чуйні (Responsive). Це забезпечує комфортну взаємодію з користувачем, що дає відчуття реального часу, і підтримуване самовідновлюватися масштабується прикладним стеком, готовим до розгортання в багатоядерних і хмарних середовищах. Кожна з чотирьох характеристик реактивної архітектури застосовується до всього технологічного стека, що відрізняє їх від ланок в багаторівневих архітектур. Розглянемо їх трохи докладніше.

Подієво-орієнтовані додатки припускають асинхронні комунікації компонент і реалізують їх слабку зв'язаність (loosely coupled design): відправник і одержувач повідомлення не потребують відомостях ні один про одного, ні про спосіб передачі повідомлення, що дозволяє їм сконцентруватися на змісті комунікацій. Крім того, що слабкозв'язаного компоненти значно покращують сопровождаемость, розширюваність і еволюціонування системи, асинхронність та неблокірующій характер їх взаємодії дозволяють також звільнити значну частину ресурсів, знизити час оклику і забезпечити б пробільшу пропускну здатність у порівнянні з традиційними програмами. Саме завдяки подієво-орієнтованої природі можливі інші риси реактивної архітектури.

масштабованість в контексті реактивного програмування - це реакція системи на зміну навантаження, тобто еластичність, що досягається можливістю додавання або звільнення обчислювальних вузлів у міру необхідності. Завдяки низькій пов'язаності, асинхронного обміну повідомленнями та незалежності від розміщення компонентів (location transparency), спосіб розгортання і топологія додатки стають рішенням часу розгортання і предметом конфігурації і адаптивних алгоритмів, що реагують на навантаження. Таким чином, обчислювальна мережа стає частиною програми, спочатку має явну розподілену природу.

відмовостійкість реактивної архітектури теж стає частиною дизайну, і це значно відрізняє її від традиційних підходів до забезпечення безперервної доступності системи шляхом резервування серверів і перехоплення управління при відмові. Стійкість такої системи досягається її здатністю коректно реагувати на збої окремих компонент, ізолювати ці збої, зберігаючи їх контекст у вигляді викликали їх повідомлень, і передавати ці повідомлення іншого компонента, здатному прийняти рішення про те, як слід обробляти помилку. Такий підхід дозволяє зберегти чистою бізнес-логіку додатка, відокремивши від неї логіку обробки збоїв, яка формулюється в явному декларативному вигляді для реєстрації, ізолювання, і обробки збоїв засобами самої системи. Для побудови таких самовідновлюються систем компоненти впорядковуються ієрархічно, і проблема ескаліруется до того рівня, який здатний її вирішити.

І наприкінці чуйність - це здатність системи реагувати на призначене для користувача вплив незалежно від навантаження і збоїв, такі додатки втягують користувача у взаємодію, створюють відчуття тісного зв'язку з системою і достатньому оснащенні для виконання поточних завдань. Чуйність актуальна не тільки в системах реального часу, а й необхідна для широкого кола додатків. Більш того, система, нездатна до швидкого відгуку навіть у момент збою, не може вважатися відмовостійкої. Чуйність досягається застосуванням спостережуваних моделей (observable models), потоків подій (event streams) і клієнтів зі станом (stateful clients). Спостережувані моделі генерують події при зміні свого стану і забезпечують взаємодію реального часу між користувачами і системами, а потоки подій надають абстракцію, на якій побудовано це взаємодія шляхом неблокірующіх асинхронних трансформацій і комунікацій.

Таким чином, реактивні додатки є збалансований підхід до вирішення широкого спектра завдань сучасної розробки ПЗ. Побудовані на подієво-орієнтованому підставі, вони надають кошти, необхідні для гарантій масштабованості і відмовостійкості і підтримують повнофункціональний чуйне призначене для користувача взаємодія. Автори очікують, що все більше число систем дотримуватиметься принципів реактивного маніфесту.

На додачу привожу план курсу без перекладу. Просто на випадок, якщо ви дочитали до цього місця, і вам все ще цікаво.

Week 1: Review of Principles of Functional Programming: substitution model, for-expressions and how they relate to monads. Introduces a new implementation of for-expressions: random value generators. Shows how this can be used in randomized testing and gives an overview of ScalaCheck, a tool which implements this idea.

Week 2: Functional programming and mutable state. What makes an object mutable? How this impacts the substitution model. Extended example: Digital circuit simulation

Week 3: Futures. Introduces futures as another monad, with for-expressions as concrete syntax. Shows how futures can be composed to avoid thread blocking. Discusses cross-thread error handling.

Week 4: Reactive stream processing. Generalizing futures to reactive computations over streams. Stream operators.

Week 5: Actors. Introduces the Actor Model, actors as encapsulated units of consistency, asynchronous message passing, discusses different message delivery semantics (at most once, at least once, exactly once) and eventual consistency.

Week 6: Supervision. Introduces reification of failure, hierarchical failure handling, the Error Kernel pattern, lifecycle monitoring, discusses transient and persistent state.

Week 7: Conversation Patterns. Discusses the management of conversational state between actors and patterns for flow control, routing of messages to pools of actors for resilience or load balancing, acknowledgement of reception to achieve reliable delivery.

Принципи реактивного програмування не нові, і їх можна простежити з 70-х і 80-х років в основоположних роботах Джима Грея і Пета Хелланд по тандемной системі.

Ці люди набагато випередили свій час. Тільки в останні 5-10 років технологічна індустрія була змушена переглянути існуючі «кращі практики» для розвитку корпоративної системи. Вона навчилася застосовувати знання про реактивних принципах сьогоднішнього світу багатоядерних і хмарних обчислень.

Основою для реактивної системи є передача повідомлень, яка створює тимчасову кордон між компонентами, дозволяє їх розв'язувати в часі, використовуючи паралельність і простір, що розподіляє навантаження і забезпечує мобільність. Ця розв'язка є вимогою повної ізоляції між компонентами і становить основу як для стійкості, так і для еластичності систем.

Основи реактивного програмування

Це програмування направлено на потоки інформації і поширення змін даних. При використанні мов програмування легко виділити статичні і динамічні потоки, при цьому базова модель автоматично поширить зміни через всі потоки даних. Говорячи простими словами, в програмування Rx, що випускаються одним компонентом, і базова структура, що надається бібліотеками Rx, буде поширювати ці зміни на інший компонент, зареєстрований для отримання цих змін. Реактивний програмування Rx складається з трьох ключових моментів.

Основні функції компонентів:

1. Спостережувані - не що інше, як потоки даних. Спостережуваний упаковує дані, які можуть передаватися з одного потоку в інший. Вони в основному випускають дані періодично або тільки один раз в своєму життєвому циклі на основі конфігурацій. Існують різні оператори, які можуть допомогти спостерігачеві відправити деякі конкретні дані на основі певних подій.
2. Спостерігачі споживають потік даних, що випромінюється спостережуваним. Спостерігачі підписуються за допомогою методу реактивного програмування subscribeOn () для отримання даних, які передають спостережуваним. Всякий раз, коли спостерігається передасть дані, всі зареєстровані спостерігачі отримують дані в зворотному виклику onNext (). Тут вони можуть виконувати різні операції, такі як розбір відповіді JSON або оновлення призначеного для користувача інтерфейсу. Якщо є помилка, викликана спостережуваним, спостерігач отримає її в onError ().
3. Планувальники (розклад) - це компонент в Rx, який повідомляє спостережуваним і спостерігачам, за яким потоку вони повинні працювати. Можна використовувати метод observOn (), щоб повідомляти спостерігачам, на якому потоці вони повинні спостерігати. Крім того, можна використовувати schedOn (), щоб повідомити спостерігається, в якому потоці вони повинні запускатися.

У реактивному програмуванні з використанням RxJava передбачені основні потоки за замовчуванням, такі як Schedulers.newThread () створять новий фон. Schedulers.io () виконає код в потоці вводу-виводу.

Основними перевагами Rx є збільшення використання обчислювальних ресурсів на багатоядерному і многопроцессорном обладнанні, підвищення продуктивності за рахунок скорочення точок і підвищення продуктивності за рахунок скорочення точок сериализации, відповідно до Закону Амдаля і Універсального закону про масштабованості Гюнтера.

Друга перевага - висока продуктивність для розробників, оскільки традиційні парадигми програмування щосили намагалися забезпечити простий і підтримуваний підхід до роботи з асинхронними і неблокірующіх обчисленнями і IO. З цими завданнями справляється функціональне реактивне програмування, оскільки воно зазвичай усуває необхідність в явній координації між активними компонентами.

Там, де виникає Rx, створюється процес створення компонентів і склад робочих процесів. Щоб повністю використовувати асинхронне виконання, включення противодавления має вирішальне значення, щоб уникнути надмірного використання або, скоріше, необмеженого споживання ресурсів. Щоб забезпечити стійкий стан з точки зору потоку даних, зворотний тиск на основі навантаження відсилає попит, що протікає вгору по потоку, і приймає повідомлення.

Таким чином, основними перевагами системи є:

1. Підвищена продуктивність - завдяки можливості швидко і стабільно обробляти величезні обсяги даних.
2. Покращений UX - через те, що додаток більше реагує на користувача.
3. Спрощені модифікації і оновлення - завдяки більш читабельного і більш легкому прогнозування коду.

Але незважаючи на те, що Reactive Programming - дуже корисна штука при створенні сучасного програмного забезпечення, щоб міркувати про систему на більш високому рівні, потрібно використовувати інший інструмент - Reactive Architecture для процесу проектування реактивних систем. Крім того, важливо пам'ятати, що існує багато парадигм програмування, і Rx - це лише один з них, як і будь-який інструмент, він не призначений для всіх випадків використання.

Стійкість реактивних систем

Стійкість - це чуйність при невдачі і є невід'ємним функціональним властивістю системи. Для неї потрібні розробки, а не просто додавання в систему в ретроактивності вигляді. Стійкість реактивного програмування javascript виходить за межі відмовостійкості і це відбувається не через деградацію, а в разі невдачі вона може повністю сама виправитися.

Для цього потрібно ізоляція компонентів і стримування відмов, щоб уникнути збоїв, що поширюються на сусідні компоненти, що може привести до катастрофічних сценаріїв з каскадними збоями. Таким чином, ключем до створення систем Resilient - самовідновлення - є те, що вони можуть бути охарактеризованими як повідомлення, відправлені на інші компоненти, які діють як супервізори і управляються з безпечного контексту поза відмовив компонента.

Тут, будучи керованими повідомленнями, ці кошти відходять від сильно пов'язаних, тендітних, глибоко вкладених синхронних ланцюжків викликів, які в більшості випадків ігноруються. Ідея полягає в тому, щоб відокремити управління відмовами від ланцюжка викликів, наприклад, звільняючи клієнта від відповідальності за обробку збоїв сервера.

Оскільки більшість систем за своєю природою складні, одним з найбільш важливих аспектів є забезпечення того, щоб системна архітектура забезпечувала мінімальне зниження продуктивності як при розробці, так і в обслуговуванні компонентів, і в той же час зменшувала випадкову складність до мінімуму. Це важливо, оскільки протягом життєвого циклу системи, якщо вона не розроблена належним чином, буде все важче і важче підтримувати працездатність, і буде потрібно все більше часу і зусиль для розуміння, щоб локалізувати і усунути проблеми.

Реактивні системи являють собою найбільш продуктивну системну архітектуру, в контексті багатоядерних, хмарних і мобільних архітектур:

1. Ізоляція відмов пропонує перебирання між компонентами, запобігаючи відмови від каскадирования і обмежуючи обсяг і ступінь відмов.
2. Ієрархії супервайзерів пропонують кілька рівнів захисту в поєднанні з можливостями самовідновлення, що усуває безліч тимчасових відмов від будь-яких експлуатаційних витрат для розслідування.
3. Пропуск передачі повідомлень і прозорість розташування дозволяють відключати і замінювати компоненти, не зачіпаючи роботу кінцевого користувача. Це знижує вартість збоїв, їх відносну актуальність, а також ресурси, необхідні для діагностики та виправлення.
4. Реплікація знижує ризик втрати даних і зменшує вплив збою на доступність пошуку і зберігання інформації.
5. Еластичність дозволяє зберігати ресурси в міру того, як використання коливається, що мінімізує експлуатаційні витрати при низькому завантаженні і ризик збоїв або термінових інвестицій в масштабованість в міру збільшення навантаження.

Веб-додатки можуть в значній мірі виграти від стилю розробки з Rx, що дозволяє скласти робочі процеси запиту-відповіді, що включають розгалуження на виклики служб, асинхронне витягання ресурсів і складання відповідей, і подальшу сортування для клієнта. Зовсім недавно push-а-серверні події і веб-сокети стали все частіше використовуватися на практиці, і для виконання цього в масштабі потрібно ефективний спосіб зберігання безлічі відкритих підключень і де IO не блокує.

Для цього є інструменти, наприклад, Streams and Futures, які роблять простими неблокірующіх і асинхронні перетворення, і підштовхує їх до клієнтів. Реактивний програмування c рівнем доступу до даних - оновлює і запитує їх в ефективному ресурсі, переважно з використанням баз даних SQL або NoSQL з асинхронними драйверами.

Веб-додатки також виграють від розробки реактивної системи для таких речей, як розподілене кешування, узгодженість даних і повідомлення з декількома вузлами. Традиційні веб-додатки зазвичай використовують стоять вузли. Але як тільки програмісти починають використовувати Server-Sent-Events (SSE) і WebSockets - ці вузли стають працездатними, оскільки, як мінімум, вони підтримують стан клієнтського з'єднання, а push-повідомлення надсилаються до них відповідним чином. Для цього потрібна розробка реактивної системи, так як це область, де важлива адресація одержувачів за допомогою обміну повідомленнями.

Суть реактивне програмування Java

Не потрібно обов'язково використовувати Rx в реактивних системах. Тому що Rx програмування і реактивні системи - не одне і теж. Хоча вони часто використовуються взаємозамінні терміни, але не є точними синонімами і відбивають різні речі. Системи являють собою наступний рівень «реактивності». Будь ласка, вважайте конкретні проектні та архітектурні рішення, які дозволяють створювати стійкі і гнучкі програми.

Проте дуже хороша ідея - комбінація методів - приносить ще більше переваг додатків, так як робить їх ще більш пов'язаними, дозволяє більш ефективно використовувати ресурси і забезпечує більш низьку затримку. Коли мова йде про величезні обсяги даних або багатозадачності, часто потрібна асинхронна обробка, щоб системи були швидкими і чуйними.

У Java - представника старого об'єктно-орієнтованого програмування, асинхронність може стати дійсно складною і зробити код важко зрозумілим і підтримуваним. Таким чином Rx особливо корисно для цієї «чисто» об'єктно-орієнтованого середовища, оскільки воно спрощує роботу з асинхронними потоками.

З його останніми випусками, починаючи з Java 8, сама Java зробила деякі спроби впровадити вбудовану реактивність, але ці спроби сьогодні не надто популярні у розробників. Проте є деякі живі і регулярно оновлювані сторонні реалізації для реактивного програмування Java, які допомагають заощадити день і тому особливо цінуються розробниками Java.

У звичайному додатку для зазвичай неодноразово виконують деякі операції реактивного програмування з використанням RxJava, тому потрібно порівняти швидкість, використання процесора і пам'яті з тими ж операціями, які були реалізовані як з співпрограмами Kotlin, так і з RxJava. Це початковий тест продуктивності.

Всякий раз, коли застосовується новий інструмент, який буде широко використовуватися в усьому кодексі, важливо зрозуміти, чи вплине воно на загальну продуктивність програми, перш ніж приймати рішення про те, наскільки доцільно використовувати його. Практика використання дає коротку відповідь: в більшості випадків користувачам варто подумати про заміну RxJava на співпрограми Kotlin, особливо в Android.

Реактивний програмування із застосуванням RxJava може як і раніше використовуватися в обмеженій кількості випадків, і в цих випадках можна змішувати, як RxJava, так і співпрограми.

Прості причини:

1. Забезпечують набагато більшу гнучкість, ніж звичайне Rx.
2. Надає багатий набір операторів в колекціях, які будуть виглядати так само, як з операторами RxJava.
3. Реактивний програмування Kotlin можуть взаємодіяти при необхідності з використанням rxjava.
4. Вони дуже легкі та ефективні, з огляду на більш високий рівень використання ЦП для збору сміття з усіх об'єктів, створених RxJava.

реактивні розширення

Reactive Extensions (ReactiveX або RX) - це бібліотека, яка слідує за принципами Rx, тобто складання асинхронних і заснованих на подіях програм з використанням спостерігається послідовності. Ці бібліотеки надають безліч інтерфейсів і методів, які допомагають розробникам писати чистий і простий код.

Реактивні розширення доступні на декількох мовах. Програмісти особливо зацікавлені в RxJava і RxAndroid, так як андроїд - це сама сфокусована область.

Реактивний програмування з використанням RxJava - це реалізація Java Reactive Extension з Netflix. В основному це бібліотека, яка становить асинхронні події, слідуючи шаблоном спостерігача.

Можна створювати асинхронний трафік, перетворювати і споживати їх спостерігачем в різних потоках даних. Бібліотека пропонує широкий спектр дивовижних операторів, таких як карта, об'єднання і фільтр, які можуть бути застосовані до потоку даних. Коли програміст почне використовувати фактичні приклади коду, він дізнається більше про операторів і перетвореннях.

Нить в додатках Android

Android "class \u003d" if uuid-2938324 "src \u003d" / misc / i / gallery / 73564 / 2938324.jpg "/\u003e

Android реактивне програмування (RxAndroid) специфічний для платформи Android з декількома доданими класами поверх RxJava. Більш конкретно - планувальники представлені в RxAndroid (AndroidSchedulers.mainThread ()), який грає важливу роль в підтримці концепції многопоточности в додатках для Android.

Крім усього іншого, фахівці радять використовувати тільки бібліотеку RxJava. Навіть завдяки великій кількості планувальників, використовуваних в програмуванні для Android.

Нижче наведено список планувальників і їх короткий зміст:

1. Schedulers.io () - використовується для виконання неінтенсивних операцій, таких як Інтернет-дзвінки, читання дисків / файлів, операцій з базами даних і який підтримує пул потоків.
2. AndroidSchedulers.mainThread () - забезпечує доступ до основної теми Thread / UI. Зазвичай в цьому потоці відбуваються операції, такі як оновлення призначеного для користувача інтерфейсу, взаємодія з користувачем. Фахівці радять користувачам, що вони не повинні виконувати будь-які інтенсивні операції над цим потоком, так як це може викликати кидок додатки або діалог ANR.
3. Schedulers.newThread () - використовуючи це, новий потік буде створений кожен раз, коли запланована завдання. Зазвичай пропонується не використовувати розклад для дуже тривалих робіт. Нитки, створені за допомогою newThread (), що не будуть повторно застосовуватися.
4. Schedulers.computation () - цей графік може застосовуватися для виконання інтенсивних операцій з процесором, по обробці величезних даних центру реактивного програмування, обробка растрових зображень. Кількість потоків, створених з використанням цього планувальника, повністю залежить від кількості доступних ядер ЦП.
5. Schedulers.single () - цей планувальник виконає всі завдання в наступному порядку, що можна використовувати, коли потрібно необхідність послідовного виконання.
6. Schedulers.immediate () - цей планувальник виконує завдання негайно, синхронно блокуючи основний потік.
7. Schedulers.trampoline () - виконує завдання в режимі First In-First Out. Всі заплановані завдання будуть виконуватися одна за одною, обмежуючи кількість потоків фону одним.
8. Schedulers.from () - дозволяє створювати планувальник від виконавця, обмежуючи кількість створюваних потоків. Коли пул потоків зайнятий, завдання будуть поставлені в чергу.

Тепер, коли є хороші теоретичні знання про RxJava і RxAndroid, можна перейти до деяких прикладів коду, щоб краще зрозуміти концепцію. Для початку роботи потрібно додати залежно RxJava і RxAndroid до проектів build.gradle і синхронізувати проект.

Програмування.

Observer підписують на Observable, щоб він міг почати отримувати дані, використовуючи два методи:

1. SubscribeOn (Schedulers.io ()) - говорить Observable, щоб запустити задачу в фоновому потоці.
2. ObservOn (AndroidSchedulers.mainThread ()) - вказує Observer отримувати дані в потоці призначеного для користувача інтерфейсу Android.

Ось і все, таким чином програміст зможе написати свою першу програму реактивного програмування з RxJava.

Підприємства і постачальники проміжного програмного забезпечення почали використовувати Reactive, а в 2016 -2018 роках спостерігався величезний ріст корпоративної зацікавленості в прийнятті цієї парадигми.

Rx пропонує продуктивність для розробників завдяки ресурсоефективності на рівні компонентів для внутрішньої логіки і перетворення потоку даних, в той час, як реактивні системи пропонують продуктивність для архітекторів і DevOps, завдяки стійкості і еластичності на рівні системи. Вони застосовуються для створення «Cloud Native» та інших широкомасштабних розподілених систем. На практиці також широко використовують книги про реактивному програмуванні Java з методами дозволяють комбінувати принципів проектування реактивних систем.

Світ ООП-розробки взагалі і мову Java зокрема живуть дуже активним життям. Тут є свої модні тенденції, і сьогодні розберемо один з головних трендів сезону - фреймворк ReactiveX. Якщо ти ще в стороні від цієї хвилі - обіцяю, вона тобі сподобається! Це точно краще, ніж джинси із завищеною талією :).

реактивний програмування

Як тільки ООП-мови доросли до масового застосування, розробники усвідомили, наскільки іноді не вистачає можливостей С-подібних мов. Оскільки написання коду в стилі функціонального програмування серйозно руйнує якість ООП-коду, а значить, і підтримувані проекту, був придуманий гібрид - реактивне програмування.

Парадигма реактивної розробки будується на ідеї постійного відстеження змін стану об'єкта. Якщо такі зміни відбулися, то всі зацікавлені об'єкти повинні отримати вже оновлені дані і працювати тільки з ними, забувши про старі.

Хорошим прикладом ідеї реактивного програмування може служити Excel-таблиця. Якщо зв'язати кілька осередків однією формулою, результат обчислення буде змінюватися кожного разу, коли зміняться дані в цих осередках. Для бухгалтерії таке динамічна зміна даних - звична справа, але для програмістів це швидше виняток.

A \u003d 3; b \u003d 4; c \u003d a + b; F1 (c); a \u003d 1; F2 (c);

У цьому прикладі функції F1 і F2 будуть працювати з різними значеннями змінної C. Часто потрібно, щоб у обох функцій були тільки найактуальніші дані, - реактивне програмування дозволить без зміни логіки самих функцій відразу ж викликати F1 з новими параметрами. Така побудова коду дає додатку можливість моментально реагувати на будь-які зміни, що зробить його швидким, гнучким і чуйним.

ReactiveX

Втілювати з нуля ідеї реактивного програмування може бути досить клопітно - є підводні камені, та й часу це займе пристойно. Тому для багатьох розробників ця парадигма залишалася тільки теоретичним матеріалом, поки не з'явився ReactiveX.

Фреймворк ReactiveX - це інструмент для реактивного програмування, що працює з усіма популярними ООП-мовами. Самі творці називають його мультиплатформенним API для асинхронної розробки, заснованим на паттерне «Спостерігач» (Observer).

Якщо термін «реактивне програмування» - це свого роду теоретична модель, то патерн «Спостерігач» - готовий механізм відстеження змін в програмі. А відстежувати їх доводиться досить часто: завантаження і оновлення даних, оповіщення про події і так далі.

Патерн «Спостерігач» існує приблизно стільки ж, скільки і саме ООП. Об'єкт, стан якого може помінятися, називається видавцем (популярний переклад терміна Observable). Всі інші учасники, яким цікаві ці зміни, - передплатники (Observer, Subscriber). Для отримання повідомлень передплатники реєструються у видавця, явно вказуючи свій ідентифікатор. Видавець час від часу генерує повідомлення, які їм же розсилаються за списком зареєстрованих передплатників.

Власне, творці ReactiveX не придумали нічого революційного, вони просто зручно реалізували патерн. І хоча в багатьох ООП-мовах, і в Java зокрема, є готові реалізації паттерна, в цьому фреймворку присутній додатковий «тюнінг», який перетворює «Спостерігач» в дуже потужний інструмент.

RxAndroid

Порт бібліотеки ReactiveX для світу Android називається rxAndroid і підключається, як завжди, через Gradle.

Compile "io.reactivex: rxandroid: 1.1.0"

Видавець, що генерує повідомлення, тут задається за допомогою класу Observable. У видавця може бути кілька передплатників, для їх реалізації скористаємося класом Subscriber. Стандартну поведінку для Observable - випустити одне або кілька повідомлень для передплатників, а потім завершити свою роботу або видати повідомлення про помилку. Як повідомлень можуть бути як змінні, так і цілі об'єкти.

Rx.Observable myObserv \u003d rx.Observable.create (new rx.Observable.OnSubscribe