Patterns in reactive programming:from transformative to reactive

Functional Reactive Programming (FRP) was introduced in 1997, and it proposed the abstraction of streams of events and behaviors that nowadays are a staple in reactive programming solutions. Due to recent technological advancements, such as the Reactive Extensions library and the Elm language, and the Reactive Manifesto that was published in 2013, more and more developers are showing interest in the abstractions that reactive programming provides. When programs are divided into reactive and transformative programs, it is seen that most programs are reactive programs that depend upon external events and respond to them. Reactive programming is a paradigm that is meant to help building these kinds of programs by providing abstractions for expressing these reactions and automatically managing the flow of time and computation dependencies. There is quite a lot of research about fixing the underlying flaws of FRP, but little research has been conducted where the usage of patterns in reactive programming has been studied. In this thesis we study how some chosen patterns are changed when they are first implemented using an imperative style, and then re-implemented using a reactive style. We find that while most of our analyzed patterns work surprisingly well when using streams, there are some scenarios where the introduction of streams permeate a clear change in the pattern. During the analysis of the Model-View-Controller model, we see that streams seem to eliminate the need for ways of explicitly requesting the most up-to-date data, at least during initialization — at least during the initialization phase. Analyzing the Chain of Responsibility and the Mediator patterns revealed that using streams somewhat diminishes the value of classes that act as “mediators”. In the Mediator pattern we saw that the Mediator class was important during the initialization phase in connecting all the modules, but once they were connected the Mediator did not necessarily do anything. The Chain of Responsibility would have undergone the most drastic transformation of all the patterns. If the pattern had been implemented by using streams in a sane way, the chain aspect of the pattern would have been lost completely. Forcibly retaining the chain would have imposed a needless limitation, and would have prevented the realization of the advantages that streams may provide.Ensimmäinen funktionaalista reaktiivista ohjelmointia (Funtional Reactive Programming, FRP) käsittelevä artikkeli julkaistiin vuonna 1997. Artikkeli esitteli ensimmäisenä abstraktiot tapahtumille (events) sekä käytöksille (behaviours), jotka ovat nykyään tärkeä osa lähes jokaista reaktiivisen ohjelmoinnin kirjastoa tai kieltä. Reaktiivinen ohjelmointi on viime vuosina kasvattanut suosiotaan — tähän ovat vaikuttaneet esimerkiksi uudet teknologiat, kuten Reactive Extensions -kirjasto ja Elm-ohjelmointikieli, sekä 2013 julkaistu Reactive Manifesto. Kun ohjelmat jaetaan kahteen kategoriaan, transformativiisin ja reaktiivisiin, huomataan että suurin osa ohjelmista on reaktiivisia. Reaktiiviset ohjelmat ovat ohjelmia, jotka riippuvat ulkoisista syötteistä ja vastaavat niihin. Reaktiivinen ohjelmointiparadigma auttaa tällaisten ohjelmien rakentamisessa antamalla ohjelmoijan käyttöön tehokkaita abstraktioita näiden reaktioiden ilmaisemiseen, sekä automaattisesti valvomalla ajankulkua ja laskennallisia riippuvuuksia. Funktionaalista reaktiivista ohjelmointia on tutkittu paljon, mutta iso osa tästä tutkimuksesta keskittyy korjaamaan kyseisen paradigman puutteita. Tässä tutkielmassa tutkimme miten tietyt valitut suunnittelumallit muuttuvat kun ne ensin toteutetaan perinteisellä, imperatiivisella tyylillä, ja sen jälkeen toteutetaan uudelleen reaktiviisella tyylillä. Toteamme, että reaktiivinen ohjelmointitapa toimii hyvin suurimmassa osassa tutkimistamme suunnittelumalleista, mutta löydämme silti tapauksia, jolloin uusi ohjelmointityyli aiheuttaa mallissa selkeitä muutoksia — hyviä tai huonoja. Model-View-Controller (MVC) mallia analysoitaessa huomattiin, että reaktiivinen ohjelmointityyli poistaa osittain tarpeen eksplisiittesti pyytää päivitettyä versiota käytettävästä datasta — uusin data on aina automaattisesti saatavilla kuuntelemalla (subscribe) tietovuota (stream). Analysoitaessa Chain of Responsibility ja Mediator-suunnittelumalleja huomattiin, että välikätenä toimivien luokkien merkitys heikkenee reaktiivisessa ohjelmoinnissa. Mediator-mallissa Mediator-luokan rooli oli oleellinen alustusvaiheessa, mutta kun muut luokat oli saatu yhdistettyä, kyseisen luokan ei ajovaiheessa tarvinnut välttämättä tehdä mitään. Chain of Responsibility-mallia ei päädytty toteuttamaan, sillä mallin toteuttaminen vaatisi, että joko mallille oleellista ketjua ei toteutettaisi sen alkuperäisessä muodossa, tai että käytössä olevia abstraktioita käytettäisiin huomattavan tehottomasti