• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The best approach for event listener

 
Hussein Baghdadi
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers.
in swing application, we have the "event listeners".
we developing my application , I used :
-------------------------------------
myButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
// some code
}
});
-------------------------------------
but borland used the following approach in thier JBuilder :
myButton.addActionListener(new Manager_myButton_actionAdapter(this));
then :
void myButton_actionPerformed(ActionEvent e) {
// some code here
}
then , in the same java file, they create a new class :
class Manager_myButton_actionAdapter implements ActionListener {
Manager adaptee;
Manager_myButton_actionAdapter(Manager adaptee) {
this.adaptee = adaptee;
}
public void actionPerformed(ActionEvent e) {
adaptee.myButton_actionPerformed(e);
}
}
so is the best approach ? and what is the approach that is used in the real applications ?
(Borland is a big company and has a long history with IDEs , so should I used their approach?)
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It depends on what you are trying to do, but personally, the first version is much more readable, and should be OK to use in the majority of circumstances. Probably the *worst* designed GUIs I have seen have been from the code created through visual GUI creators, so I would definately not try to learn good coding habits from code generation tools. This design just probably makes it easier for the GUI design tool to keep track of what listeners go with what buttons.

The only times you might want to not use the anonymous ActionListener defined in place would be if you need to reuse the ActionListener somewhere else. It's also possible to run into performance problems by defining so many small classes, but I've really never seen this to be an issue in any of the code I've worked on... you'd probably have to have millions of anonymous ActionListners for this to be a real problem.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic