Reputation: 231
What I'm having trouble understanding is how exactly a method such as
public interface MouseListener extends EventListener {
public void mouseClicked(MouseEvent e) {
//code for what happens when you click the mouse on the component
}
}
knows the id of the mouse event. Why is the event only sent to the mouseClicked method when the event is performed? The constructors for these methods call for any of the possible mouse events so why is it only sent to the mouseClicked method when other methods have the same constructor (i.e. mousePressed, mouseReleased, etc.)
Upvotes: 4
Views: 117
Reputation: 2114
Such an interface starts to be useful when you implement it, create an object and register that object to an event source. The registration part is critical here - if you register to mouse click events, then that's what the object will receive.
So basically these interfaces look alike because they are used to handle similar events, but in the end you will be informed only about the events you register to. There is no magic here - an event source internally keeps a collection of the listeners which are interested in some event and if such an event occurs, it iterates over the collection and invokes the listener method.
For example the mouse listener interface you mentioned has a couple of methods:
public interface MouseListener extends EventListener {
public void mouseClicked(MouseEvent e);
public void mousePressed(MouseEvent e);
...
}
if you look at part of the java.awt.Component
class you'll see that it's the event source that
takes care of calling the right method:
public abstract class Component implements ImageObserver, MenuContainer,
Serializable
{
...
protected void processMouseEvent(MouseEvent e) {
MouseListener listener = mouseListener;
if (listener != null) {
int id = e.getID();
switch(id) {
case MouseEvent.MOUSE_PRESSED:
listener.mousePressed(e); // invoking a specific listener's method
break;
case MouseEvent.MOUSE_RELEASED:
listener.mouseReleased(e);
break;
...
}
Upvotes: 3
Reputation: 95978
The Observer Pattern is the important thing to know.
This pattern is used to form relationships between objects at runtime.
The idea behind the pattern is simple - one of more Observers are interested in the state of a Subject and register their interest with the Subject by attaching themselves. When something changes in our Subject that the Observer may be interested in, a notify message is sent, which calls the update method in each Observer. When the Observer is no longer interested in the Subject's state, they can simply detatch themselves.
The whole idea of action listeners is based on this. Once you understand this pattern, it's straightforward.
When you register an ActionListener, it's the observer and the button is the subject. So when the button changes state, the actionPerformed method will be launched.
Note that all listeners are based on this pattern, when an event occurs, the registered ones will be notified about this event and will perform the actions. Swing, for example, manages all of the registering and event notification by itself (it's already "built in").
(http://java.dzone.com/articles/design-patterns-uncovered)
Upvotes: 5
Reputation: 562
When you register for the event you pass the listener to the object you want to hear from. This object keeps a list of objects it that are interested and if something warranting notification happens then it iterates over the list and calls the notification method.
Upvotes: -1