Listeners are an Observer implementation?

Question

I’m trying to understand the concept of Observer and its implementation, and I ended up finding this example where it is used listeners instead of classes observable and observer:

This graph has been removed of this link, where an alternative way to implement the same concept in java is explained, but using the classes EventObject and EventListener, package java.util.

Listeners are the basis of Swing/AWT, and by repairing the way that the actions of the graphic components are monitored, along with the example above, I noticed a certain resemblance to the Observer pattern.

The implementation using Listeners (as in the example above and in Swing) would be a way of applying the Observer standard?

There is some difference of applicability between this form and using the classes Observable/Observer?

Listeners increase coupling compared to Observable/Observer?

Answer 1

Yes, it’s the same. If you pay attention, the names are a little different, but the function is the same. Observer or listener gives in the same. Subject or source...

It has several ways to do and get the same result, everything applies the standard if it meets some requirements. That’s why I say that pattern should not be followed as if it were a cake recipe. It is, but everything deserves adaptation.

There is a larger coupling by the example shown. But I do not know if it is intentional for this case. The fact that there is coupling may have been purposeful for this example. It’s a way of requiring the observer to be written in a certain way in order to be able to sign that event. It is more common to leave a standard method name for everything. It is usually chosen notify(). But deep down, the coupling is the least it has to be. I don’t know if the name will affect so much, since the method has to know what to do with that specific event.

But that’s up to an old Java deficiency. In languages that allow to have functions passed as parameters (almost all languages) the name of the method does not matter, even is passed an anonymous method.

What the standard requires:

• be able to add and remove a method to a list of subscribers/listeners;
• have a way to warn the entire list that a particular action has occurred;
• the observer must have a method (subscriber/listener) capable of receiving the information about who is notifying him and what is his current state.

The "list" was on me, as far as I know there’s nothing that requires a list. Of course a list is much more useful, without it, it could only have one subscriber at a time and the others would fail to try to sign (at least so I hope in a "good implementation", if we can call it that).

The rest is implementation detail. I understand that what is out there is very academic and confuses, the pattern is simpler than it seems.

See the diagram on Wikipedia. The code example already complicates.

To tell you the truth I find the way Java does this very confusing. I recommend using a simplest way with Java 8 (this example is more complicated than it should be, but it’s just what I found).

A document with an interesting view on this pattern.

Just as an addition, C# has event which further facilitates the creation of the standard. This mechanism allied to the delegate which is the basis for the lambda and event, was the reason C# existed. Sun did not accept that Microsoft put this in Java by creating the split for J++, then J# and C#.