TEM Journal. Volume 10, Issue 1, Pages 18-30, ISSN 2217-8309, DOI: 10.18421/TEM101-03, February 2021. Reactor Design Pattern Marko Mijač 1, Antonio García-Cabot 2, Vjeran Strahonja 1 1University of Zagreb, Faculty of Organization and Informatics, Varaždin, Croatia 2University of Alcalá, Computer Science Department, Alcalá de Henares, Spain Abstract – In object-oriented (OO) applications, paradigm is "object", which encapsulates state objects collaborate through message passing, which (attributes) and associated behavior (methods) of results in these objects being coupled and mutually concepts in the problem domain. Each object has its dependent. These dependencies can be reactive, i.e. responsibility and is expected to contribute to the such that, for example, the state change of one object, overall goal of the application. In this process, requires automatic reaction in all dependent objects. Examples of such reactive dependencies can be found objects collaborate in a form of message passing, i.e. in various software systems, including rich graphical invoking other objects’ behavior, or fetching their interfaces, spreadsheet systems, animation, robotics, state. This results in objects being coupled and etc. Unlike the reactive paradigm which natively mutually dependent. provides abstractions and mechanisms for the Dependencies between objects can sometimes be management of reactive dependencies, the OO reactive, i.e. such that for example the state change in paradigm lacks proper support. Object-oriented one object, automatically triggers an update of state applications developers often resort to the use of ad- in all dependent objects. Dependent objects need to hoc solutions or design patterns such as the well-known recognize the occurrence of something interesting Observer pattern, which are not suitable for managing happening and react accordingly. Examples of such more complex scenarios. In this paper we offer a novel design pattern (REACTOR), which utilizes a graph reactive dependencies can be found in several data structure to improve the management of reactive software systems, including rich graphical user dependencies in OO applications. interfaces, spreadsheets, animation, modeling, etc. OO paradigm lacks native support for managing Keywords – design patterns, design science, object- reactive dependencies. Instead, the well-known oriented paradigm, reactive paradigm Observer design pattern (or some variant of it) is mostly used as a solution. Observer’s overall idea is 1. Introduction to “Define a one-to-many dependency between objects so that when one object changes state, all its The Object-oriented (OO) paradigm dominates in dependents are notified and updated automatically" the modeling and development of large and complex [1]. This coincides with the idea of reactive software systems. The central abstraction of this dependencies, however, the use of Observer has several shortcomings that made it heavily criticized as unfit for complex use (e.g. in [2], [3] and [4]). DOI: 10.18421/TEM101-03 Indeed, when managing a large number of mutually https://doi.org/10.18421/TEM101-03 interconnected reactive dependencies, the following Corresponding author: Marko Mijač, issues may arise: (1) failing to react and update Department of Information Systems Development, Faculty dependent objects when there is a need for it; (2) of Organization and Informatics, Pavlinska 2, Varaždin, reacting and updating defensively and redundantly Croatia. when there is no need for it; (3) updating in the Email: [email protected] wrong order and thus causing inconsistencies (so- called glitches); (4) forming circular dependencies Received: 10 November 2020. which cause infinite loops, etc. In order to address Revised: 09 December 2020. these issues, we propose a novel design pattern, Accepted: 16 December 2020. Published: 27 February 2021. which uses well-known graph structures to express reactive dependencies and support related operations. © 2021 Marko Mijač, Antonio García-Cabot & The rest of the paper starts with presenting related Vjeran Strahonja; published by UIKTEN. This work is work (section 2), followed by a description of the licensed under the Creative Commons Attribution- chosen research paradigm and methodological NonCommercial-NoDerivs 4.0 License. framework (section 3). Outcomes of activities and The article is published with Open Access at steps prescribed by the methodological framework www.temjournal.com are contained in section 4. Finally, contributions are discussed and conclusions offered in section 5. 18 TEM Journal – Volume 10 / Number 1 / 2021. TEM Journal. Volume 10, Issue 1, Pages 18-30, ISSN 2217-8309, DOI: 10.18421/TEM101-03, February 2021. 2. Related Work "event-triggered signal sent to a run-time recipient" [8]. This signal is usually sent either by transferring The concept of reactive dependencies described in data or transferring execution control. the previous section has been recognized by both Faison [8] describes two principal roles essential in academy and industry and is related to several fields event-based interaction. The first role is commonly of research. Reactive programming, event-based referred to as event publisher/sender and it describes programming, and aspect-oriented programming are an entity able to produce an event and send a examples of relevant research fields. Solutions notification. The second role, commonly referred to offered in these fields differ in approach and scale as event subscriber/receiver, describes an entity able and take different forms, ranging from design to receive notification and react to it. The act of patterns, libraries and frameworks, specialized sending the notification is often called firing the programming languages, and language extensions. event, while the act of establishing the link between Bainomugisha et al. [5] in their extensive survey sender and receiver is called subscription or define reactive programming as a paradigm centered registration [8]. Similarly, Hinze et al. [9] classify around the issues of continuous time-varying values parts of the event-based system into (1) monitoring and propagation of change. These issues are tackled component, (2) transmission mechanism, and (3) by providing abstractions able to express and reactive component. While monitoring and reactive automate the flow of time, as well as abstractions for components correspond to event sender and event expressing data and computational dependencies. receiver roles respectively, transmission mechanisms Thus, they identify two distinguishing abstractions describe how notifications are sent and received. If offered by reactive programming languages: (1) notifications are exchanged directly between sender behaviors or signals and (2) events. Based on these and receiver, we talk about decentralized, point-to- built-in abstractions some solutions from the fields of point systems. However, often a separate, third reactive programming provide a mechanism for component is introduced to decouple senders and automated management of reactive dependencies. receivers and route notifications throughout the Most of the research in the field of reactive system. Such an approach is called a centralized or programming stems from representatives of middleware approach. functional-reactive languages such as Fran [6], which At the core of event-based programming is the idea is why reactive programming has a strong functional- of implicit invocation, which according to Steimann declarative flavor as opposed to the imperative style et al. [10] can be considered as both an architectural of OO programming. Recent trends, however, style and programming paradigm. Since being acknowledge the advantages and disadvantages of introduced by Garlan and Notkin [11], it is frequently both reactive and object-oriented paradigm and aim used to implement inversion of control and achieve at reconciling them. Boix et al. [7] identify two loose integration of objects and components. While approaches for this: the first taking reactive in traditional systems the components usually interact programming, and the second taking OO by explicitly invoking each other's methods, implicit programming as a starting point. Their ROAM invocation relies on events instead. A component, framework implemented in AmbientTalk acting as a sender, can publish one or more events as programming language is an example of the second a means of informing other components that some approach. Conversely, REScala is an example of the significant change happened. Other components, first approach [2]. acting as receivers, can express their interest in these Event-driven programming is a paradigm events by subscribing to it. Whenever the sender specifically suited for the development of event- component triggers an event, all subscribed based systems. According to Faison [8], these are the components invoke their event handling methods systems whose elements primarily interact through (thus the name implicit). Now, instead of sender event notifications. Similarly, Hinze et al. [9] component being required to know its receivers, describe them as systems in which observed events receivers are required to know the sender (thus the cause reactions. Most of today's software systems, name inversion of control). According to Notkin et especially the ones with graphical user interfaces, are al. [12], implicit invocation makes it easier to add, event-based. modify, and integrate new components, without the At the core of the event-based paradigm is the