Anzahl Event Listeners

[Timeeh]

Hallo!

Ich habe mich bisher nur wenige Stunden mit Java Swing beschäftigt und bin daher noch ziemlicher Anfänger!
Das nur mal so als Warnung vorne weg 🙂

Mich interessiert folgendes:
Angenommen ich habe ein GUI mit 4 Buttons, auf die ich reagieren will (z.B. in dem ich irgendeinen Text ausgebe).
Wie viele event listener kann ich dafür minimal und maximal benutzen?
Ich würde schätzen, dass ich minimal einen benutzen kann, indem ich einfach einen Eventlistener schreibe und mit allein Buttons registriere, der sich
mit getSource den Button holt, von dem die Aktion kam, und dann geeignet reagieren kann.
Weniger geht denke ich nicht, schließlich muss ich doch auf Buttonclicks reagieren.

Maximal würde ich jetzt sagen 4 Eventlistener, für jeden Button einfach einen eigenen. Bzw. theoretisch gingen auch unendlich viele, denn ich kann doch einfach event listener implementieren und registrieren die einfach nichts tun.

Was könnten nun Gründe sein, mehr oder weniger Eventlistener zu verwenden?

Danke,
euer Timeeh

 

[Marco13]

Das hängt ein bißchen vom Zusammehang ab. Es gibt sicher auch Fälle, wo man einen Listener an mehrere Buttons hängt. Häufiger vielleicht sogar an mehrere "andere Components", wenn z.B. ein und dieselbe Aktion sowohl durch einen Menüeintrag als auch durch einen Button ausgelöst werden soll. (Speziell das würde man durch Actions lösen, soll nur ein verdeutlichendes Beispiel sein).

Ganz allgemein ist es aber NICHT empfehlenswert, mehrere (insbesondere nicht-verwandte) Aktionen in einem Listener zusammenzufassen: Wenn in der "actionPerformed" dann erstmal 20 Zeilen wie
if (source == buttonX) { ... }
else if (source == buttonY) { ... }
oder
if (actionCommand.equals("bla")) { ... }
else if (actionCommand.equals("blubb")) { ... }
stehen, wird das schnell unübersichtlich, und man verdengelt Dinge, die man eher getrennt halten sollte.

Der umgekehrte Fall, mehrere Listener an einem Button, kann schon eher vorkommen, und ist auch vollkommen OK: Wenn jemand mitkriegen will, ob ein Button geklickt wurde, registriert man ihn als Listener, und ob vorher schon 10 andere Listener da dran hängen, hat denjenigen nicht zu interessieren. Er will Events -> er kriegt Events.

Ich persönlich finde in vielen Fällen anonyme Listener praktisch, die NUR eine (i.a. private) Methode aufrufen - im Stil von

startButton.addActionListener(new ActionListener()
{
    public void actionPerformed(ActionEvent e)
    {
        start();
    }
});

stopButton.addActionListener(new ActionListener()
{
    public void actionPerformed(ActionEvent e)
    {
        stop();
    }
});

Damit kann man dort, wo der Button erstellt wird, dem Button auch eine klar definierte Funktion zuweisen. (Eigentlich sollte man auch das eher mit Actions machen, aber in einigen Fällen (und bei anderen Listener-Typen) passt dieses Muster schon ganz gut). Hat ein bißchen Ähnlichkeit mit den "Slots und Signals", wie sie in Qt verwendet werden - aber das nur nebenbei.

 

[Timeeh]

Hallo Marco!

Der einzige Grund warum man einen Listener nicht an mehrere Buttons hängen soll ist aber dann der, dass der "actionPerformed"-Block einfach unübersichtlich und zu lange wird?
Auf der anderen Seite spart man sich aber die Erstellung vieler Listener...
Ich bin noch nicht so ganz überzeugt..denn mein actionPerformed für die 4 Buttons ist denke ich noch gut lesbar 🙂

 

[SlaterB]

wenn der Listener aufwendiger wird, z.B. Zustand merkt wie Anzahl Klicks, oder ähnlich komische Dinge, dann kommen entsprechend mehr Überlegungen hinzu,

im einfachen häufigen Fall hat man aber wirklich nur die Frage zwischen mehreren Einzellistenern oder if/else im gemeinsamen, richtig

 

[Marco13]

Ja, es klingt erstmal nach einer recht "unbedeutenden" Entscheidung - aber (ohne jetzt Buzzwords wie "Separation of concerns" verwenden zu wollen) : Mehrere Listener zu einem zusammenfassen ist vermutlich immer einfacher, als einen verwobenen Mega-Listener auseinanderzupflücken. Wenn ein Button in eine andere (GUI)-Klasse wandern soll kann der Aufwand dafür schon ~"nicht unerheblich" sein.