Difference between Observer, Pub/Sub, and Data Binding

Question

What is the difference between the Observer Pattern, Publish/Subscribe, and Data Binding?

I searched around a bit on Stack Overflow and did not find any good answers.

What I have come to believe is that data binding is a generic term and there are different ways of implementing it such as the Observer Pattern or the Pub/Sub pattern. With the Observer pattern, an Observable updates its Observers. With Pub/Sub, 0-many publishers can publish messages of certain classes and 0-many subscribers can subscribe to messages of certain classes.

Are there other patterns of implementing "data binding"?

Orthohydrogen

I found another one: dirty checking which is what Angular.js does. More info here: https://mcmap.net/q/36672/-how-does-data-binding-work-in-angularjs – Orthohydrogen

Answer 1

Here's my take on the three:

Data Binding

Essentially, at the core this just means "the value of property X on object Y is semantically bound to the value of property A on object B. No assumptions are made as to how Y knows or is fed changes on object B.

Observer, or Observable/Observer

A design pattern by which an object is imbued with the ability to notify others of specific events - typically done using actual events, which are kind of like slots in the object with the shape of a specific function/method. The observable is the one who provides notifications, and the observer receives those notifications. In .net, the observable can expose an event and the observer subscribes to that event with an "event handler" shaped hook. No assumptions are made about the specific mechanism which notifications occur, nor about the number of observers one observable can notify.

Pub/Sub

Another name (perhaps with more "broadcast" semantics) of the Observable/Observer pattern, which usually implies a more "dynamic" flavor - observers can subscribe or unsubscribe to notifications and one observable can "shout out" to multiple observers. In .NET, one can use the standard events for this, since events are a form of MulticastDelegate, and so can support delivery of events to multiple subscribers, and also support unsubscription. Pub/Sub has a slightly different meaning in certain contexts, usually involving more "anonymity" between event and eventer, which can be facilitated by any number of abstractions, usually involving some "middle man" (such as a message queue) who knows all parties, but the individual parties don't know about each other.

Data Binding, Redux

In many "MVC-like" patterns, the observable exposes some manner of "property changed notification" that also contains information about the specific property changed. The observer is implicit, usually created by the framework, and subscribes to these notifications via some binding syntax to specifically identify an object and property, and the "event handler" just copies the new value over, potentially triggering any update or refresh logic.

Data binding re Redux

An alternative implementation for data binding? Ok, here's a stupid one:

• a background thread is started that constantly checks the bound property on an object.
• if that thread detects that the value of the property has changed since last check, copy the value over to the bound item.

Imbecilic

I do appreciate your answer and attempt to implement a different data binding idea. – Orthohydrogen

@jessemon heh, no problem; the observer pattern is definitely the "abstractly best" approach that I'm aware of, but my horrible little example would also "do data binding", albeit in a chaotic and inefficient manner. – Imbecilic

Honestly, I'm tired of hearing "pub/sub aka the observer pattern", they are not at all the same thing. Pub/sub is an event system, the observer pattern uses an event system to publish events AUTOMATICALLY on change of the object. If you're manually emitting events whenever you change an object, you're not using the observer pattern. – Marvismarwin

yes. we can say the "data binding" is the theory concept, and the "pub/sub" and "observable" patterns are implementation of this theory concept with special features based in specified context. – Circumstantial

Answer 2

There are two major differences between Observer/Observable and Publisher/Subscriber patterns:

1. Observer/Observable pattern is mostly implemented in a synchronous way, i.e. the observable calls the appropriate method of all its observers when some event occurs. The Publisher/Subscriber pattern is mostly implemented in an asynchronous way (using message queue).

2. In the Observer/Observable pattern, the observers are aware of the observable. Whereas, in Publisher/Subscriber, publishers and subscribers don't need to know each other. They simply communicate with the help of message queues.

As you mentioned correctly, data binding is a generic term and it can be implemented using either Observer/Observable or Publisher/Subscriber method. Data is the Publisher/Observable.

Moloch

I was reading JavaScript Web Applications by O'Reilly (shop.oreilly.com/product/0636920018421.do). In Chapter 2 Alex implements a pub/sub using JS events. It is a callback type of implementation, but it is a synchronous example. – Orthohydrogen

I haven't read the book but if it was implemented using JS "events", it would be asynchronous since events are asynchronous by definition. – Moloch

Hi Param. I like your answer. It's really good. I'm just refining it to say that pub/sub is not always asynchronous. Reference: #15924514 – Orthohydrogen

Hi Jess, of course you are right. There is no standard definition for these terms 😊 – Moloch

Generally an observable has a list of observers with it (it iterates over this list to send an event to all of them). A publisher is generally aware of only a queue where it publishes its events/messages. It doesn't know how many consumers have subscribed to that queue. – Moloch

For me, this is the crucial difference between the two: Also, in the observer pattern, the observers are aware of the observable. Whereas, in Pub/Sub, neither the publishers, nor the consumers need to know each other. They simply communicate with the help of message queues. Great answer! – Oblate

medium.com/@huytrongnguyen1985/… – Peter

@Param, I think it would be better to say that the observable is aware of its observers. – Sherwood

@Moloch To say that JS events are always asynchronous by definition is false. Trusted browser events are asynchronous, but all events dispatched by library code, except for message events dispatched via post message, are synchronous. – Olgaolguin

@batbrat, thank you! I'am wondering why we're the only persons here that have noticed it – Beutner

Answer 3

I am a bit amused that all the answers here were trying to explain the subtle difference between Observer and Pub/Sub patterns without giving any concrete examples. I bet most of the readers still don't know how to implement each one by reading one is synchronous and the other is asynchronous.

One thing to note is: The goal of these patterns is trying to decouple code

The Observer is a design pattern where an object (known as a subject) maintains a list of objects depending on it (observers), automatically notifying them of any changes to state.

Observer pattern

This means an observable object has a list where it keeps all its observers(which are usually functions). and can traverse this list and invoke these functions when it feels a good time.

see this observer pattern example for details.

This pattern is good when you want to listen for any data change on an object and update other UI views correspondingly.

But the Cons are Observables only maintain one array for keeping observers (in the example, the array is observersList).

It does NOT differentiate how the update is triggered because it only has one notify function, which triggers all the functions stored in that array.

If we want to group observers handlers based on different events. We just need to modify that observersList to an Object like

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

see this pubsub example for details.

and people call this variation as pub/sub. So you can trigger different functions based on the events you published.

Amaranthaceous

Well this is a much better, concise and clear answer. :) – Daubery

At a high level I've always said that the pub sub is the observer pattern but with everything it has different flavors. – Fulminous

Answer 4

I agree with your conclusion about both patterns, nevertheless, for me, I use Observable when I'm in the same process and I use the Pub/Sub in inter-process scenarios, where all parties only know the common channel but not the parties.

I don't know other patterns, or let me say this way, I've never needed another patterns for this task. Even most MVC frameworks and data binding implementations use usually internally the observer concept.

If you're interested in inter-process communication, I recommend you:

"Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" - https://www.enterpriseintegrationpatterns.com/

This book contains a lot of ideas about how to send messages between processes or classes that can be used even in intra-process communication tasks (it helped me to program in a more loose-coupled way).

I hope this helps!

Colonial

Answer 5

One concrete difference is that an Observable is always engaged when an observer no longer wants to observe. But a subscriber can stop the subscription and the publisher will never be aware of these intent to unsubscribe

Advertisement