ActionListener pragmatischer Ansatz gesucht

[FenchelT]

Hallo zusammen,

normalerweise, wenn ich ein GUI mit zwei oder drei Button habe, arbeite ich mit innere Klassen wobei jede Klasse einen eigenen ActionListener implementiert.

Beispiel:

public class MyTest
{
   private JButton btnSpeichern;

      public MyTest()
      {
            initComponents();
      }

      private void initComponents()
      {
           btnSpeichern = new JButton("Speichern);
           btnSpeichern.addActionListener(new btnSpeichernListern());
      }


      class btnSpeichernListener implements ActionListener
      {
           public void actionPerformed........usw
      }

}

So habe ich die Moeglichkeit jedem Button seinen eigenen Listener zuzuweisen und muss nicht mittels
if (event.getActionCommand......) pruefen, welcher Button gedrueckt wurde, weil ich das nicht gerade performant finde.

Nun habe ich allerdings das Problem, dass ich eine GUI mit 20 Schaltflaechen habe.

Wie macht ihr sowas, wenn mehrere Schaltflaechen auf der GUI sind.
Prueft ihr alle mit if() ab und wenn ja, wie wirkt sich das auf die Performance aus, oder arbeitet ihr auch mit inneren KLassen oder wie macht ihr das?


Vielen Dank und viele Gruesse
FenchelT

 

[Marco13]

"Das kommt drauf an" :wink:

Ich finde normalerweise anonyme Listener recht praktisch - also nicht

btnSpeichern.addActionListener(new btnSpeichernListern());

class btnSpeichernListener implements ActionListener
{
           public void actionPerformed........usw
}

sondern

btnSpeichern.addActionListener(new ActionListener()
{
           public void actionPerformed........usw
});

In der actionPerformed kann man dann (je nachdem, was dort gemacht werden soll) u.U. nur eine einzige, private Methode aufrufen. (Das erinnert vom Konzept her an die "Slots" von QT). Jedenfalls finde ich das am flexibelsten: Wenn man will, kann man dann die "umschließende" Klasse zum ActionListener machen, und ruft in der ActionPerformed einfach die gleiche private Methode auf, oder man lagert die private Methode in eine eigene Klasse aus, die ein ActionListener ist, und hängt DEN dan an den Button. Beide "Richtungen" sind mit ca. 3 Zeilen code erledigt.

 

[FenchelT]

Hallo Marco,

danke erstmal fuer Deinen Post.

"Das kommt drauf an" :wink:

Wenn man will, kann man dann die "umschließende" Klasse zum ActionListener machen, und ruft in der ActionPerformed einfach die gleiche private Methode auf, oder man lagert die private Methode in eine eigene Klasse aus, die ein ActionListener ist, und hängt DEN dan an den Button. Beide "Richtungen" sind mit ca. 3 Zeilen code erledigt.

Ehrlich gesagt stehe ich im Moment ein wenig auf dem Schlauch, was Du mir damit sagen willst :roll:


Natuerlich haben anonyme Listener einen gewissen Charme, aber ich mache mir ein paar Gedanken hinsichtlich der Performance. In einer annon. Listener Klasse muss ich ja mit if(event.getActionCommand.....) pruefen,
welcher Button gedrueckt wurde und da ich noch nicht in die Verlegenheit gekommen bin, ueber 20 Button auf einer
GUI anzusprechen und habe halt wie gesagt bedenken was die Performance angeht.
Hast Du da evtl. Erfahrungen?

Vllt sagt ihr mir ja auch uebereinstimmend, "....mensch die Kisten sind heute so schnell, da brauchst Du Dir keine Gedanken mehr ueber die Performance zu machen" :?: :!:

Moechte halt nicht erst die Erfahrung machen, wenn ich alles in eine KLasse gepackt habe und dann merke, verdammt, zu langsam.

Auf der anderen Seite moechte ich mir auch ungern die ganze Tiparbeit mit den inneren Klassen machen, wenn es mit einer Klasse und >20 if() auch performant laeuft.


Danke nochmals fuer DEine Unterstuetzung.

 

[Marco13]

Vllt sagt ihr mir ja auch uebereinstimmend, "....mensch die Kisten sind heute so schnell, da brauchst Du Dir keine Gedanken mehr ueber die Performance zu machen" :?: :!:

Zumindest ich sage das - in gewisser Hinsicht. Was sowas angeht braucht man sich um die Performance auf keinen Fall Gedanken zu machen. Bis die Schallwellen vom Klicken der Maus das Ohr des Anwenders erreichen, hat der Computer vielleicht schon 100 Stringvergleiche gemacht :wink: Aber ich finde solche ewig langen if-elseif-Konstrukte mehr als häßlich und unübersichtlich.

In einer annon. Listener Klasse muss ich ja mit if(event.getActionCommand.....) pruefen, welcher Button gedrueckt wurde

Nein, genau das eben nicht. Jeder Button kann ja seinen eigenen, kleinen Listener haben, der NUR auf diesen einen Button hört

button1.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { machWasFürButton1(); }});
button2.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { machWasFürButton2(); }});
button3.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { machWasFürButton3(); }});

Die "machWasFürButtonX()" sind dann eben die besagten privaten Methoden. Man hat also nicht eine riesige actionPerformed mit vielen if-elseif-Anweisungen, sondern einen Button, der mit einer "einzigen" Zeile mit einer bestimmten Funktionalität verknüpft wird. Die Verbindung zwischen dem Button und dem, was der Button wird damit i.a. genau dort hergestellt, wo auch der Button erstellt wird, und ohne irgendwelche Abfragen. Es KANN zwar auch Fälle geben, wo andere Konstrukte auch OK sind, aber ich persönlich finde das so ziemlich praktisch - flexibel, übersichtlich und leicht wartbar. Nachteile würden mir jetzt nicht einfallen. Außer vielleicht, dass es schöner wäre, nicht

button1.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { machWasFürButton1(); }});

schreiben zu müssen, sondern vielleicht sowas wie

button1.setActionMethod("machWasFürButton1()");

aber das ginge nur mit übelsten Reflection-Hacks :wink:

 

[FenchelT]

Moin Marco,

wusste doch, dass ich DIch nicht richtig verstanden hatte :wink:
Danke fuer das Beispiel, ueber die MOeglichkeit hatte ich nich so noch gar nicht nachgedacht ???:L

Auf jeden Fall gefaellt mir diese Loesung sehr, werde ich dankend uebernehmen


Danke nochmals fuer Deine Unterstuetzung.

Schoenen Tag noch
und viele Gruesse
FenchelT