Difference between Observer Pattern and Event-Driven Approach

Question

I always found the Observer Pattern almost similar to the usual event-driven approach. Actually, I have almost believed that they are actually just different names referring to the same thing. They both use similar concepts to have something as a listener and even in the implementation, they are almost the same thing, that's to have a callback method/function to carry out an action. This is at least in Java.

In other languages say Actionscript/Flex, the events are more user-friendly and may look like it does more than just the observer pattern defines. But still, the concepts sound the same.

But is this really true? Is the Observer Pattern the same thing as the usual event-driven programming style?

possible duplicate of [How is the Observer pattern different from an Event driven model?](http://stackoverflow.com/questions/807778/how-is-the-observer-pattern-different-from-an-event-driven-model) — nawfal, Jan 11 '15 at 12:26
[What do you mean by “Event-Driven”?](https://martinfowler.com/articles/201701-event-driven.html) — jaco0646, Jun 02 '20 at 15:01

score 53 · Accepted Answer · answered Jun 22 '11 at 14:10

53

The Observer Pattern is a very special instance. Event-Driven can mean anything. In most Observer Pattern implementations the Observer is an object watching the observee. When the observee is changed, a method of the observer is called. Strictly speaking this is not an "Event". That means: various different actions on the observee, usually lead to the call of different methods in the observer. The semantics "what" got changed is in the method. In Event Driven Systems, you basically have one consuming object/method and the message what was changed or what happend is in the Event. That can be anything and is not limitd to the idea of observing something! That means: in an Event Driven System you get new semantics by adding new Event types. In an Observer Pattern you usually add semantics by adding a method to the Observer class. HOWEVER: no one is preventing you to implement an Observer as a special listern to ChangeEvents.

answered Jun 22 '11 at 14:10

Angel O'Sphere

2,642
20
18

210

Reading this confused me even more. – crush Jun 04 '13 at 19:33
1

@crush may I add an example for more clarification, in Java, the EDT is an event bus it captures all the events that system sent, let's say a button click, the EDT will dispatch the click event, the button will catch it -note that the parent container of the button may catch the event as well and the button itself may catch other type of events-, this is an example of Event pattern. now the button has registered listeners, that got notified and called from the button delivering this event, this registeration is is an example of observer pattern – DrAhmedJava Jul 06 '15 at 07:14
5

So, events are like broadcasts with no intended receiver while observer pattern is like multicast, where receiver is directly observing for signal from observable? – Gulshan Mar 28 '16 at 07:11
1

Is one of the logical implication of **in most Observer Pattern implementations the Observer is an object watching the observee** that in order to be properly called Object Pattern the object-observer and observee must have a single degree of separation (e.g. the observer is directly watching the observee) and if so would this constitute a difference from Event-Driven or is this not the case? – Peter David Carter Mar 30 '16 at 07:35

Zeigeist · Answer 2 · 2017-11-05T18:28:16.680

45

When there is a state change at the Publisher or Subject,

Event Driven Architecture (is a message-driven architecture), responsible to deliver message to Subscriber, asynchronously.
Observer Pattern (is a software design pattern), responsible to command Subscriber to do something, synchronously.

edited Nov 05 '17 at 18:28

answered Jun 12 '16 at 05:27

Zeigeist

3,755
3
20
22

From [Wikipedia](https://en.wikipedia.org/wiki/Observer%20pattern): "[...] [Observer] pattern thus suits any process by which data arrives from some input that is not available to the CPU at startup, but instead arrives seemingly at random (HTTP requests, GPIO data, user input from peripherals, distributed databases and blockchains, etc.)." Does this conflicts with the "synchronous" description pointed here? – perrocallcenter Jul 23 '23 at 22:03

Mohan · Answer 3 · 2018-04-08T07:07:06.660

23

Event-driven programming is a term to define a paradigm. whereas Observable pattern is a design solution to make an application event-driven.

Cheers!

edited Apr 08 '18 at 07:07

answered Apr 08 '18 at 06:43

Mohan

4,755
2
27
20

1

Where is the source of this quote? (assuming it's a quote since the block quote formatting is used here). Also it's "Observer pattern", not "Observable pattern". https://en.wikipedia.org/wiki/Observer_pattern – jkasten Jan 25 '23 at 22:31
Aside the lack of source, I believe this is the correct answer. Event-driven is mainly referred to as an architecture paradigm with no concrete implementation but rather a description of a software design that can scalate to entire systems. On the other hand, the Observer pattern is a solution for this necessity; developers use its principles to solve their problems in a better way. – perrocallcenter Jul 23 '23 at 22:35

score 15 · Answer 4 · answered Mar 15 '13 at 05:14

The diffrence No.1 may be, that Event-Systems always have an eventdispatchthread which decouples observables from its observers so events may not reach the observers immediatly. While real observables call observer methods directly, event driven observables drop their events into an eventqueue. Then the EDT deliveres those events to registered listeners.

thekingoftruth · Answer 5 · 2018-12-13T19:36:36.410

Synthesizing from multiple answers in this question, this hackernoon article, and my own experience, the key difference between the Observer Pattern and Event-Driven (Pub-Sub, say) Architecture is, in my mind, this:

In the Observer Pattern, the Observed maintains references to its Observers.

Whereas in Pub-Sub, the Broadcaster has no idea who its Listener(s) are. (Or even if anyone is there to listen.) The Listener may expect some data from the Broadcaster, but has no idea exactly where the event comes from. Maybe it comes from multiple classes or remote systems. Maybe not. It doesn't matter to either the Broadcaster or Listener.

Now, that's not to say these things are very different. Also, there are implementations that behave like either or both.

For example, the wisper rubygem allows you to act like either an Observer pattern or a Pub-Sub pattern depending on your need. You can even use both together if you like.

score 5 · Answer 6 · answered Dec 18 '19 at 21:40

One of the great things about the observer pattern is safety. When code changes occur within the observee object, all observants must implement the new changes. If we would have used events instead, the event listener would not react to the implementation of new events. In other words, the observee dictates that events must be handled by the observers.

In one of my projects I came across a situation where one of the observee objects became destroyed and observers needed to be notified, before doing so. The only thing that I had to do was add the notification as a requirment for all of the observers, and fire the event before the observee got destroyed. The beauty here is that the code only compiles if all observers implement a handler for the newly created event, therefore you will less likely forget to change a few of them. In my case I had a decent amount of possible observers, and it is nice to know that I can make changes without creating a few or more hidden bugs.

These qualities makes the observer pattern less flexible than simply throw an event, and let the observers decide for themselfs. But, when using events, beware for the great spaghetti monster that hides around the corner, and only comes out when deadlines are near. There's probably more than a few of you that have, just like me, come across this ugly beast more than once.

In other words, be as pragmatic as possible and still use the right tools for the job. This means using event when you need flexibility and the observer when you need control.

score 3 · Answer 7 · answered Jun 22 '11 at 12:10

3

Yes, they are the mainly same.

Events are something like a "built-in" observer pattern template for some languages.

Thus, you wouldn't really implement the observer pattern in a language which supports events as they already provide what you are looking for.
On the other hand, you can write event-driven in languages which lack events by using the observer pattern.

answered Jun 22 '11 at 12:10

Matthias

12,053
4
49
91

1

I would say one big difference between the Observer/Pubsub pattern and just straight up events is that heavy use of events can introduce very tight coupling between the objects in your system whereas an observer or a hub as an intermediary promotes looser coupling - an object subscribed to a particular topic doesn't need to have any "knowledge" whatsoever of the object that's publishing the topic. – natlee75 Feb 02 '12 at 22:42

score 2 · Answer 8 · answered Aug 12 '16 at 05:31

I've searched a bit for this same question. For this thread, I find point from Angel O'Sphere on "What semantics" and point from Spacerat on "Dispatcher" do helps.

That two points are my understanding that distinguish Even-Driver from Observer Pattern. At least from canonical explanation, "Observer Pattern" usually represents an immediate broadcasting once the "Subject" has changed and the "Dispatching" is implemented by calling the interface provided by subscriber or listener. While for Event-Driven, there is always another layer between "Subject and "Observer". Either called "Dispatcher" or using "Event Queue". This provides the "delayed" handling to reduce CPU usage and also provides certain capability on calling different interfaces depends on different event type.

Anna Klein · Answer 9 · 2018-04-16T09:36:13.817

I try it very simple, because that helped me once too.

Just think as a Observer and Observable. Instead that the observable marks a setChanged and the observer requests from the observable what has changed, the observable instead broadcasts an object (Event Carried State) with all relevant information about the change to the observers. So there is actually one more instance between the Observer and the Observable.

http://www.grahambrooks.com/event-driven-architecture/patterns/stateful-event-pattern/

score 1 · Answer 10 · answered May 12 '17 at 19:05

The basic difference in both is coupling and synchronous behaviour. If we stick with observer pattern, we say there is only one source of signal and it would be synchronous, while on other hand with events, we decouple both parties to work independently and the same time entertain the possibility of having more than one source of events in future without any code changes. Events help us to embrace async as design. All Reactive programming library provide very good support for event driven design.

score 1 · Answer 11 · answered Nov 26 '19 at 17:34

Event-driven is a software paradigm or style of writing code where objects communicate using events. Some languages like C# have native support for events. You can have an object raise an event to which another object listens to. The Observer Pattern is another way to achieve the same result.

John Smith · Answer 12 · 2017-05-13T03:18:06.320

From Wikipedia :

The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

It is mainly used to implement distributed event handling systems, in "event driven" software. Most modern languages such as Java and C# have built in "event" constructs which implement the observer pattern components, for easy programming and short code.

The observer pattern is a little more abstract and theoretical. Events are one (commonly built-in) implementation, however as noted in Angel's answer Events tend to be able to be used in a few other situations apart from what is strictly defined in the observer pattern.

Difference between Observer Pattern and Event-Driven Approach

12 Answers12

Linked