Programarea reactiva in Java. Reactivitate

Programarea reactiva este unul dintre cele mai populare trenduri in ziua de azi. Invatarea acestei abordari este insa un proces greoi, mai ales atunci cand nu ai materialele potrivite. Aceasta serie de articole este menita sa functioneze ca un rezumat al intregii teorii.

In cadrul seriei noastre anterioare despre programarea reactiva, ne-am concentrat pe a explica motivele pentru care a aparut, unde este aplicata si ce poate aduce conceptul de asincronicitate la acest mix. In aceasta serie noua vom discuta despre urmatorul pas care sa ne permita sa beneficiem la maxim de asincronicitate — programarea reactiva.

Reactivitate

Programarea reactiva este asincronicitatea combinata cu streaming-ul de date. Cu alte cuvinte, nu exista thread blocking in procesarea asincrona, insa datele sunt procesate in portiuni. Reactivitatea adauga capacitatea de a procesa date intr-un flow. In seria anterioara am dat un exemplu unde managerul aloca o sarcina lui John, care la randul lui trebuie sa dea mai departe rezultatul catre Jim, si Jim ar trebui sa il dea mai departe catre manager? Insa sarcina noastra este o parte specifica, peste care nu putem trece pana nu este finalizata. O asemenea abordare poate sa ajute la eliminarea unor sarcini de care se ocupa managerul, dar Jim si John stau inactivi o perioada deoarece Jim trebuie sa astepte rezultatele de la John si John trebuie sa astepte sa primeasca o noua sarcina.

Acum sa ne imaginam ca aceasta sarcina a fost impartita in mai multe subsarcini si ca ele se afla in acelasi stream continuu de date.

Cand Henry Ford a inventat banda rulanta, a reusit sa creasca performanta de pana la 4 ori, si a facut masinile accesibile pentru majoritatea populatiei. Aici putem sa vedem acelasi lucru: avem portiuni mici de date si banda cu threadul de date. Apoi fiecare handler trece datele prin ele, si le transforma intr-un anumit fel. Execution threads functioneaza precum John and Jim, oferind multi-thread data processing.

Acesta schema arata diferite tehnologii de streaming care au fost adaugate la versiunile Java. Dupa cum putem vedea, Reactive Streams este deasupra: nu inlocuieste tot ce era acolo dar adauga cel mai inalt nivel de abstractizare, lucru care il face usor si eficient de folosit.

Idea de reactivitate se bazeaza pe Observer design pattern.

Tine minte acest pattern. Avem abonati si ceva la care se aboneaza. Twitter este un exemplu bun aici, dar poate sa fie orice alta comunitate sau persoana dintr-o retea sociala la care te abonezi si primesti actualizari. O data ce te-ai abonat, toti abonatii primesc notificari cand apare un mesaj nou. Acesta este un pattern de baza.

In aceasta schema, avem:

• Publishers — cei care publica mesajele
• Observers — cei care se aboneaza la ele. In cazul reactive streams, observers sunt, de obicei, numiti abonati. Sunt doi termeni diferiti pentru aproximativ acelasi lucru. Majoritatea comunitatilor folosesc termenele de Publisher/Subscriber

Este o idee de baza pe care sunt construite multe sisteme.

Un exemplu din viata reala unde avem reactivitate este un sistem de alarma in caz de incendiu. Sa presupunem ca trebuie sa construim un sistem care activeaza alarma in cazul in care avem fum foarte mult sau temperatura ridicata.

Avem un detector de fum si un termometru. In momentul in care avem prea mult fum si/sau temperatura este prea mare, valorile senzorilor respectivi vor creste. Cand valorile legate de temperatura si fum trec peste un anumit prag, alarma suna.

Daca am fi folosit o abordare traditionala (non-reactiva), am fi scris cod care interoga detectorul de fum si senzorul de temperatura la fiecare 5 minute si apoi activa sau nu alarma. In cazul abordari reactive, insa, acest lucru este facut de un framework reactiv si noi doar setam conditiile: alarma este activata cand valoarea aferenta detectorului de fum este mai mare decat X, si temperatura este peste Y. Functioneaza de fiecare data cand apare un eveniment.

Un thread de date pleaca de la detectorul de fum: spre exemplu, valoarea 10, apoi 12, etc. Temperatura se poate schimba si ea, este un alt thread de date — 20, 25, 15. De fiecare data cand apare o noua valoare, rezultatul este recalculat, lucru care duce sau nu la activarea alarmei. Ar trebui doar sa stabilim o conditie pe baza careia alarma sa fie pornita.
In termeni de Observer pattern, detectorul de fum si senzorul de temperatura sunt Publishers (surse de date), si alarma se aboneaza la ei. Este un Subscriber (sau Observer).

Acum ca putem intelege mai bine idea de reactivitate, in urmatorul articol vom intra mai mult in detalii. Vom discuta despre reactive programming operators. Operatorii ne permit sa transformam threaduri de date intr-un anumit fel, schimband datele si creand threaduri noi. Spre exemplu, sa ne uitam la operatorul distinctUntilChanged. Elimina aceleasi valori care urmeaza una dupa alta. Daca valoarea detectorului de fum este aceeasi, ar trebui sa reactionam si sa recalculam.

Articolul original poate sa fie citit aici.

Vrei sa inveti sa programezi cu Java sau sa iti imbunatatesti abilitatile de programare in Java? Parcurge cursurile noastre.

Originally published at https://www.luxoft-training.ro.