Reactor Design Pattern

Abstract

In object-oriented (OO) applications, objects collaborate through message passing, which results in these objects being coupled and mutually dependent. These dependencies can be reactive, i.e. such that, for example, the state change of one object, requires automatic reaction in all dependent objects. Examples of such reactive dependencies can be found in various software systems, including rich graphical interfaces, spreadsheet systems, animation, robotics, etc. Unlike the reactive paradigm which natively provides abstractions and mechanisms for the management of reactive dependencies, the OO paradigm lacks proper support. Object-oriented applications developers often resort to the use of ad-hoc solutions or design patterns such as the well-known Observer pattern, which are not suitable for managing more complex scenarios. In this paper we offer a novel design pattern (REACTOR), which utilizes a graph data structure to improve the management of reactive dependencies in OO applications.

Following the Writer’s Path to the Dynamically Coalescing Reactive Chains Design Pattern

“…In Sections 3-12, we elaborated the DCRC software pattern by following the steps on the writer's path, applying relevant pattern-writing patterns along the way. In this section, we first demonstrate the technical feasibility and efficacy [4,39] of the DCRC pattern by applying it to an arbitrary GUI application developed using C# and the built-in .NET GUI framework.…”

“…Mijač et al [29] evaluates these patterns extensively and finds "a great similarity between considered design patterns, especially in their overall idea and intent", but identifies "features that should be considered when dealing with complex propagation scenarios." In subsequent work, Mijač et al [4] proposes the REACTOR design pattern to include these improved features. Mijač et al [35] then incorporates these ideas into an application framework named RE-FRAME, which "provides built-in abstractions, mechanisms and tools for handling reactive dependencies" in the C#/.NET context.…”

“…Therefore, it may take several cycles of the display system for the states of all components to be updated and the user interface to reach a stable state. This period of transitional turbulence [2] (or glitchiness [3,4]) can result in displays in which the visible states of the components do not meet the users' expectations of the user interface's behavior. Due to these inconsistent displays, users can (at least temporarily) perceive the system to be unreliable and inaccurate.…”

“…We must be careful to separate the problem from its solution and make sure that the solution actually solves the problem. 4.…”

“…For the cases we studied, the writer's path enabled us to capture this structure and draft an appropriate software pattern. In the future, it may be useful to revise the writer's path methodology to incorporate the insights of Riehle et al [50], Iba [19], design science methodologists [4,40], and others.…”