ActionListener implementieren oder Eigenen für jede Komponente?

[GilbertGrape]

Hallo Gemeinde,
ich hab mal ne ganz allgemeine Frage.
Mich interessiert, ob es irgendeinen Unterschied macht, ob man einen ActionListener direkt implementiert (wie im ersten Beispiel) oder eben für jeden Button eine eigene Inline-Implementierung macht?
Ich meine, ist das eine schöner als das andere oder performanter oder was? Ich finde, von der Übersichtlichkeit nimmt es sich nicht so viel.
Ich weiß, dass ich im 2. Fall mehr class-Dateien hab.
Ich überleg nämlich jedes Mal wie ich es mache. Das hat dazu geführt, dass ich es nicht konsistent mache, mal so und mal so. Wenn ich das jetzt einheitlich mache, wüsste ich gerne, was besser ist.
Meinungen?


[highlight=Java]class Tester implements ActionListener {

public void actionPerformed(ActionEvent e) {
if (e.getActionCommand().equals("Bla")) {
btnBlaClicked();
}
}


private void btnBlaClicked() {

}

}[/highlight]

[highlight=Java]class Tester {

private void initButtons(){
btnBla.addActionListener(new ActionListener(){

public void actionPerformed(ActionEvent e) {
btnBlaClicked();

}

});
}

private void btnBlaClicked() {

}

}[/highlight]

Gruß, Gilbert

 

[mvitz]

Performancemäßig kann ich dir da nichts zu sagen. Ich persönlich nutze entweder einen ActionListener als eigene Klasse und Datei oder als Anonymen Listener (dein Beispiel 2). Eine Innere Klasse benutze ich eher selten.

Das ganze ist imho in erster Linie immer eine persönliche Entscheidung. Für kurze einmalige Aufrufe finde ich z.B. den Anonymen Listener sehr passend. Ist nicht sonderlich lang, ist direkt am Button zu erstellen. Für wiederkehrende Aktionen benutze ich dann wie gesagt gerne eine eigene Klassen in einer eigenen java Datei.

 

[Marco13]

Performance spielt dort keine Rolle. Wenn man mit der Maus auf einen Button klickt, kann der Computer in der Zeit, die der Schall braucht, um von der Maus bis zum Ohr zu kommen, ungefähr 1 Million Zahlen addieren.

Subjektiv finde ich es nicht schön, wenn man einen riiieeesen ActionListener hat, der in seiner ActionPeformed dann so eine

if (actionCommand.equals("foo")) doFoo();
else if (actionCommand.equals("bar")) doBar();
else if (actionCommand.equals("...")) do...();
...

-Kaskade macht. Das wird besonders häßlich, wenn man die Funktionalitäten neu verteilt oder in andere Klassen veschiebt, und man den ganzen Schmodder dann zerpflücken muss....

Genauso unschön finde ich aber "große" anonyme innere Klassen.

Deswegen bevorzuge ich einen anonymen ActionListener, der in der actionPerformed NICHTS macht, außer EINER Methode aufzurufen. Das ist übersichtlich, man hat die Verbindung zwischen dem Button und dem, was der Button tut auf einen Blick, und das ganze ist ggf. recht schnell und flexibel zu ändern....

 

[GilbertGrape]

Deswegen bevorzuge ich einen anonymen ActionListener, der in der actionPerformed NICHTS macht, außer EINER Methode aufzurufen. Das ist übersichtlich, man hat die Verbindung zwischen dem Button und dem, was der Button tut auf einen Blick, und das ganze ist ggf. recht schnell und flexibel zu ändern....

Also so wie in meinem 2. Beispiel?

 

[Marco13]

Ja, und wenn man nicht mehr als 10 Zeichen pro Antwort eintippen würde, würde dieser Satz nur aus seinem ersten Wort bestehen.

 

[Ebenius]

Sun empfiehlt, für Buttons in der Regel am besten auf ActionListener zu verzichten und Actions zu benutzen. Eine Action pro Aktion; die kann dann natürlich auf verschiedenen Buttons oder Menüeinträgen liegen. Außer in Test-Code (oder hier im Forum) halte ich mich strikt daran und habe mich schon mehrfach darüber gefreut, diese Entscheidung getroffen zu haben.

Ebenius

 

[mvitz]

Ein kurzes Codebeispiel wäre ganz nett.

Meinst du das so?:
[HIGHLIGHT="Java"] // Create an action
Action action = new AbstractAction("Button Label") {
// This method is called when the button is pressed
public void actionPerformed(ActionEvent evt) {
// Perform action...
}
};

// Create the button
JButton button = new JButton(action);
[/HIGHLIGHT]
http://www.exampledepot.com/egs/javax.swing/button_Button.html

Und hast du evtl einen Link der erklärt, was an Actions besser als an einem ActionListener ist?

 

[Ebenius]

Ein kurzes Codebeispiel wäre ganz nett. [...]

Hast recht, hätte ich machen können. Aber Deines ist so in Ordnung.

Mehr hier:

• Sun Java Tutorial: How to Use Actions
• Sun Tech Article: Using the Swing Action Architecture

Und hast du evtl einen Link der erklärt, was an Actions besser als an einem ActionListener ist?

Ich habe vor Ewigkeiten darüber einen guten Artikel irgendwo bei Sun gefunden. Aber ich finde ihn leider nicht wieder.

Actions werden auf exakt die gleiche Weise an vielen Stellen im Swing benutzt. Du kannst die gleichen Actions benutzen in:

• Menüs
• Buttons
• ToolBars
• Radio Buttons
• Check Boxes
• ActionMaps (zusammen mit InputMap)
• ...

Actions bringen von Haus aus Accelerator-Key-Support mit. Actions trennen die Darstellung eines Buttons (...) von dessen Zustand (enabled, tooltip, name, etc.) was den GUI-Code nicht kürzer aber aufgeräumter macht. Mehr kann ich mir grad nich zusammenlügen.

Ebenius

 

[Marco13]

Sun empfiehlt, für Buttons in der Regel am besten auf ActionListener zu verzichten und Actions zu benutzen.
Hui. Man sollte auch auf Collections verzichten, und stattdessen ArrayLists verwenden Aber mal im ernst: Ich weiß, was gemeint ist - Actions bieten bei "komplexeren" Projekten, die auch benutzerfreundlich sein sollen (ggf. mit Hotkeys, Mnemonics, I18N und allem drum und dran) etliche Vorteile. Trotzdem bleibe ich im wesentlichen bei meiner Aussage:
Deswegen bevorzuge ich einen anonymen ActionListener, der in der actionPerformed NICHTS macht, außer EINER Methode aufzurufen.
Dieser ActionListener kann auch eine Action sein (die dann nicht mehr so ganz Anonym ist, aber fast ). Ich finde, dass diese Action (genau wie im einfacheren Fall der anonyme ActionListener) nur als Verbindungs-Flansch fungieren sollte, zwischen dem Button, und dem, was der Button tut, und nicht irgendwelchen "komplexeren" Code enthalten sollte...

 

[Ebenius]

Den größten Teil meiner S/W-Entwicklungszeit verbringe ich entweder in größeren Projekten oder in welchen die dazu werden.

Ich hab in eine geerbte ~2.000-Klassen-GUI nachträglich I18N-Support einbauen dürfen. Über eine bessere Trennung zwischen Actions und deren Komponenten hätte ich mich wirklich gefreut.

Ebenius