By now we have seen how parallel and functional programming constructs in the .NET world help one naturally compose algorithms/business logic and model programs/data flows. These paradigms help realize a software system that has close correlation with the real world in which they exist. We have seen relevance of data structures and their role in program composition. We also saw the benefits (in terms of concurrency and parallelism) of keeping the data structures (modeled in an object-oriented way) different from the algorithms (modelled as pure function compositions) that consume them. To take this one knot further, in order to keep up with growing system complexity, there's a growing software revolution called reactive programming, which defines how to model applications from a behavior stand-point. In this chapter, we will try to unravel the concept through some examples, and understand how this programming paradigm becomes a natural succession, but more importantly, a unifying model for creating responsive systems. We will look at the various reactive programming constructs (including key data structures, interfaces, and operators) available in .NET Reactive Extensions (Rx). By the end of the chapter, you will understand how natural it is to model responsiveness, which becomes quite relevant in this new world of multicore, cloud, mobile, and web-scale systems.
To start with, let's look at the classic definition of reactive programming, and try to understand the concept brought forth by this model. This is important to undo any misconceptions that govern one's mind on this topic.
In computing, reactive programming is a programming paradigm that maintains a continuous interaction with their environment, but at a speed which is determined by the environment, not the program itself. | ||
| --Gèrard Berry | ||
This implies that this programming model helps, or rather, has an inherent capability to propagate changes without the programmer having to explicitly wire any such logic (the conventional way, which was error prone and rendered programs inconsistent; a nightmare that still haunts some of us). This would mean that the programming model would be declarative and provide the needed constructs (including data structures and interfaces) to capture the relationship between attributes in order to ensure seamless propagation or synchronization of changes through data flows.
Let's try to understand this further via this example. In typical assignment statements (in the imperative world), relations are implicitly declared (say c2 = a2 + b2 , the Pythagorean equation that symbolizes the Pythagorean theorem), or functions (in the functional programming world) are defined explicitly, say c = Compute Hypotenuse(a, b). On the other hand, in the reactive world, computation (value of c) is automatically done with new values of the sides (a and b). The computation is automatically triggered every time the value changes for a and b in the relation c2 = a2 + b2. This behavior is termed as reactive. You could say that this is similar to event-driven programming, but there is a very distinct difference here that you need to understand.
This behavior is extremely important to model concurrent real-world systems including real-time analytics, control systems with feedback loops, electronic circuits and printed circuit board (PCB) design, rule engine, state machines, simulators, and so on.