Difference between Observer Pattern and Event-Driven Approach

46,704

Solution 1

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.

Solution 2

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.

Solution 3

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

Cheers!

Solution 4

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.

Solution 5

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.

Share:
46,704

Related videos on Youtube

Carven
Author by

Carven

Updated on July 05, 2022

Comments

  • Carven
    Carven almost 2 years

    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?

  • natlee75
    natlee75 over 12 years
    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.
  • crush
    crush about 11 years
    Reading this confused me even more.
  • DrAhmedJava
    DrAhmedJava almost 9 years
    @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
  • Mac
    Mac over 8 years
    So, events are like broadcasts with no intended receiver while observer pattern is like multicast, where receiver is directly observing for signal from observable?
  • Peter David Carter
    Peter David Carter about 8 years
    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?