Ask HN: What is the relation between Rx Observables and “raw” OO objects?

4 points by pezo1919 ↗ HN
I think I have lack of a deeper understanding Rx especially its relation to OOP. By OOP (which is an overloaded term today) I mean message passing - like in Erlang.

To me every Observable seems like a piece of a state (aka object) which sends messages (events) to other Observables (objects).

If so, question arise:

* When to use "raw" objects which respond to events through their methods (1 method ~= 1 event), and when to use Observables?

* Is there anything an Observable can't do but a "raw" object can? Is there anything a "raw" object can't do, but Observable can? Simplicity, expressiveness matters!

* Shall I replace every object with an Observable? Are Observables "just superior" in every way? If not: what are the exceptions?

5 comments

[ 2.7 ms ] story [ 23.2 ms ] thread
Observables are a powerful abstraction, but with great power comes great complexity (so use them only when you expect/require updates)

An observable can be created from an event and have several transformations applied to that event (see https://www.learnrxjs.io/). These transformations functions are powerful because they can be composed to create the observable and can also be shared and reused.

They are not "just superior in every way", they are just suited to listening and emitting events to/from various components in your system. A simple object is perfect if no events are needed.

"A simple object is perfect if no events are needed."

To my understanding calling an objects <any_method> can be interpreted as the object receives the message named <any_method> (with additional args).

From that point of view there is nothing but messages: method calls are also messages, so that part "no events are needed" does not hold, because if methods are needed then virtually events are needed.

"so use them only when you expect/require updates": To me, it turned out I always expect/require update. The only question is in what form of. Via method calls consecutive or via "explicit" events. My intuition says that using Observables won't change the problems inherent complexity in any direction. << That's the real, deep question I think.

So if there are useful transformation functions to use with observables I don't know why not to use them in every case.

> From that point of view there is nothing but messages.

Yes this is true. The observable's implemented by Rx is an interesting abstraction that can act as an emitter OR a listener of messages (events).

The events emitted from an Observable can be an object with methods. However, you need to subscribe to the observable to get the object and call those methods.

> To me, it turned out I always expect/require update.

Yes, most systems will need to send updates around to various components in the system. Rx is a great option for these use cases.

> So if there are useful transformation functions to use with Observables I don't know why not to use them in every case.

The complexity of an event-driven system is why you generally shouldn't use them every where. Events inherently make things more complex and harder to debug as dependencies between components become implicit rather than an explicit function call.

My advice is to use Rx to decouple parts of your system. But try to stick with the KISS principle and keep things simple to understand.

[1] https://en.wikipedia.org/wiki/KISS_principle

I'm a former maintainer of RxJava so my answer might have a Java tint to it.

I would describe Observable as representing an uninitiated computation. More analogous to function reference than an Object with state. If you delve deep into an observable implementation you'll likely find that the only concrete property is the function to invoke on subscription.

As an exercise replace "Observable" with "function" in each of your questions and see if they still make sense.

That sounds weird to me, but I'm not a maintainer at all! :D "Uninitiated computation" isn't more like "good old" Command Pattern?

To me Observables and (its methods) seem more capable.