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"?

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.

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/Subscriber.

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.

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" - http://www.addison-wesley.de/9780321200686.html

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!