Difference between Observer Pattern and Event-Driven Approach

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.

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.

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.