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) 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?
Best Answer
This is the Observer pattern - it's the exact same thing.
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
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.
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).