What's the difference between Observer pattern and listeners?

Question

I have used some kind of "listeners" where I have an interface implemented by classes that need to be notified of some event (e.g.: CurrencyListener, with a method currencyUpdated(Currency currency)) Then, the object that needs to send a notification, has a list of listeners (List<CurrencyListener>) and just iterates over this list invoking the currencyUpdated(Currency currency) method.

The structure of this listener, is very similar to the Observer pattern, there is no Observer and Observable class, just the listener interface (CurrencyListener).

What are the advantages/disadvantages of using one approach over the other?

Answer 1

This is the Observer pattern - it's the exact same thing.

I have used some kind of "listeners" where I have an interface implemented by classes that need to be notified of some event (e.g.: CurrencyListener, with a method currencyUpdated(Currency currency))

In the Observer pattern, you have an abstraction (an interface or a base class) Observer which defines the things the observer can observe (or listen for). Your CurrencyListener is the Observer.

The other part of the pattern is the Observable, which is the object that sends notifications, which may or may not be itself an abstraction, or part of some hierarchy. I.e., the pattern does not require the ConcreteObservable subclases to be present. In the Go4 Patterns book, one of the roles for a ConcreteObservable is described as

"stores state of interest to ConcreteObserver objects."

If a ConcreteObserver can has no need for any special state, or can work with just the interface provided by the Observable base class, then there's no need for a ConcreteObservable.

Then, the object that needs to send a notification, has a list of listeners (List) and just iterates over this list invoking the currencyUpdated(Currency currency) method

The Observer provides methods for the Observables/Listeners to register with it, and it internally maintains a collection of these listeners. That's exactly what your object does.

Again, it's just the classic Observer pattern. The Observers and the Observables are independent of each other because they both depend on the abstraction provided by the Observer interface, and because they rely on the client code that uses them to hook up the Observers/Listeners with the Observable.

P.S. There's a number of variations on the pattern, and a number of features in different languages that are just the Observer pattern in disguise. For example, in C#, events are clearly a variation of the pattern. Another example of a variation would be what's usually called a Messenger (or an Event Aggregator, as Martin Fowler calls it), an can be found in some libraries and frameworks - it's a class that acts as as an intermediary between the observers and the observables. The structure is slightly different, but it is based around the Observer pattern; in fact, the Go4 book describes something similar near the end of the Implementation section in the description of the pattern (they call it ChangeManager).

Answer 2

In short

Your listeners are very close to be observers. However they seem to be tightly coupled to a very specific observed subject (e.g. Currency). In consequence, listening to other type of subjects would require additional listener interfaces and additional implementation of similar dispatching methods.

The original observer pattern, on contrary, ensures reusability and extendability by providing an abstract coupling between the observed subject (hereafter called observable) and the observers. This allows each side of the pattern to be specialized further independently.

In conclusion, your listeners are not quite observers.

---

In long, with plenty of details

Your design

I understand the following design:

• Your concrete listeners all implement the CurrencyListener interface with a specific method CurrencyListener.currencyUpdated(Currency currency).
• You have other listener interfaces for other kind of updates with other implementations.
• The notification sender holds a list of CurrencyListener,
• The notification sender iterates over this list and fires their currencyUpdated() methods.

Open issues:

• You don't tell how you add/remove listeners to the notification sender. It's not a major question here, but the observer pattern could inspire you about this point.
• You don't tell if the state of the notification sender is used by the listener (typical for an observer) or if currency is the object that the listener listens to (typical variant of the observer pattern, used when the same observer has to look at multiple observables). Hereafter, I will assume the latter.

Mapping your design with the observer pattern

Comparing your design with the Observer design pattern suggests that:

• The notification sender is an Observable (unless Currency is)
• The list of of listeners is a collection of Observer
• The CurrencyListener is an Observer interface
• The CurrencyUpdated() method is an update() method
• The concrete listeners are concrete Observer

What's the difference ?

• Your notification sender and your Currency are not an abstract interface but is a concrete class. They do not either seem to be a general class that offers an interface that would be abstract enough. This means that your observers all depend on that concrete class (strong coupling instead of abstract coupling).
• The Observer pattern has a registration mechanism to add/remove observers to an observable. (But maybe you have too but didn't tell?)
• Your CurrencyListener imposes the concrete type of object that the update function will receive. And this type seems to be very specific and closely linked to the notification sender. So implementing listeners for a new kind of observables requires each time a new interface.
• On the contrary, the Observer.update() doesn't need to know the concrete Observable. This allows to decouple the implementations. The concrete Observer knows the concrete Observable and can get its state. A known variant is Observer.update(Observable o). So observers remain decoupled from a (too) concrete implementation of observable.

Conclusions:

Your listeners are fine. If you would have only one kind of observable subjects, they could even simplify the design.

But refactoring them using the observer pattern may help to decouple the parts, which could facilitate reuse and improve flexibility.

Answer 3

They are the same thing, the observer pattern is a pattern, listener is the implementation based on that pattern.

The other answers just pointed out the way you name your methods doesn't make your observer system reusable. So just try to use "update" instead of "updateCurrency" for naming the method.