I\'m trying to differentiate between listeners and adapters.
Are they pretty much the same but in listeners you have to implement all the methods in the interface, but w
WindowListener is interface
which force you to override
all of the methods, while WindowAdapter is implementation of WindowListener
and you only need to override
the method(s) that you interest to deal with.
WindowListener
is interface which mean you cant instantiation the WindowListener
, while WindowAdapter
is concrete class that you can use new
operator to instantiation.
When you use WindowAdapter
, the code is more clean where your class only override the method(s) that you want.
For example:
public class CloseListener implements WindowListener {
// im not interest on this event, but still need to override it
@Override
public void windowOpened(WindowEvent e) {
}
// im not interest on this event, but still need to override it
@Override
public void windowClosing(WindowEvent e) {
}
@Override
public void windowClosed(WindowEvent e) {
System.exit(0);
}
// im not interest on this event, but still need to override it
@Override
public void windowIconified(WindowEvent e) {
}
// im not interest on this event, but still need to override it
@Override
public void windowDeiconified(WindowEvent e) {
}
}
While using adapter the code is cleaner:
// at JFrame class
addWindowListener(new CloseListener());
// reusable Close Listener
public class CloseListener extends WindowAdapter {
@Override
public void windowClosed(WindowEvent e) {
System.exit(0);
}
}
Or
addWindowListener(new WindowAdapter() {
@Override
public void windowClosed(WindowEvent e) {
System.exit(0);
}
});
So I would recommend to use WindowAdapter
, but not must follow. However, two of the API about the same just that WindowAdapter
exists as convenience for creating listener objects.
EDIT:
Since WindowListener
is interface
, you can implement it at your JFrame subclass.
public class MainWindow extends JFrame implements WindowListener {
// this is ok
}
public class MainWindow extends JFrame, WindowAdapter {
// this is not allow
}
But you cant do it with WindowAdapter
.
There are several Adapter classes such as the MouseAdapter, KeyAdapter, WindowAdapter that one can extend thus avoiding writing the methods that you don't actuality need.
The thing with interfaces is that you have to write out all the methods you do not need. The Adapter class can further be Sub Classed as a way to override the method required.
http://www.cafeaulait.org/course/week7/19.html
Listeners are used when you plan to utilize most of the interface methods. When you need to use only a few of the methods an adapter would be better b/c you would not have to override the remainder of the methods.
You can do everything with either, but if you start with the interface, your code is going to have a LOT of boilerplate. I'm sure you noticed that when you tried it out. That statement about instantiation etc. is a quite convoluted way of saying it and there's a lot of confusion of terms. You can write
c.addWindowListener(new WindowListener() {
@Override public void windowActivated(WindowEvent arg0) { }
@Override public void windowClosed(WindowEvent arg0) { System.exit(0); }
@Override public void windowClosing(WindowEvent arg0) { }
@Override public void windowDeactivated(WindowEvent arg0) { }
@Override public void windowDeiconified(WindowEvent arg0) { }
@Override public void windowIconified(WindowEvent arg0) { }
@Override public void windowOpened(WindowEvent arg0) { }
});
or you can write
c.addWindowListener(new WindowAdapter() {
@Override public void windowClosed(WindowEvent arg0) { System.exit(0); }
});
In neither case are you instantiating either WindowListener
or WindowAdapter
—you are creating anonymous classes that implement WindowListener
/extend WindowAdapter
. But when you implement the interface directly, you are forced to implement all methods, wheras when you extend the adapter class, you can only override what you need. That class already has exactly these empty implementations that you had to write in the Listener
case.
There is another aspect which is not addressed in other answers: API evolution. Providing adapter classes (a.k.a empty or default implementations of interfaces) makes introducing new methods in interfaces less painful. If an API provides only interfaces then clients are forced to implement them and if a new method is added to the interfaces then all implementing classes will break. However, if default implementations are provided then clients have the chance to extend those instead which, apart from being convenient, helps them upgrading to newer API version. With default methods of Java 8 default/empty implementation have become less important but they might be handy in older versions.