ActionListener per Innere Klasse oder e.getActionCommand() if-Abfrage?

Jack159

Bekanntes Mitglied
Hallo,

Wenn es darum geht einen JFrame mit mehreren Buttons zu erstellen, in dem jeder Button etwas anderes tun soll, was wäre dann die bessere Variante?

Innere Klassen:
Java:
ActionListener c = new ActionListener(){
			public void actionPerformed(ActionEvent e){
				//tu dies und das....				
			}
		};
		b3.addActionListener(c);


oder mit dieser if-Abfrage:
Java:
//Weiter oben im Code:
button1.setActionCommand("button1");
button2.setActionCommand("button2");
button3.setActionCommand("button3");

/....

public void actionPerformed(ActionEvent e) {
		if (e.getActionCommand().equals("button1")) {
			//Tue dies bei Button1
		} else if (e.getActionCommand().equals("button2")) {
			//Tue dies bei Button2
		} else if (e.getActionCommand().equals("button3")) {
                       //Tue dies bei Button3
		}

	}
 
Genrell muss ich sagen, dass ich Variante 1 so schöner finde. Allerdings ist es ja meist so, dass du so evtl. sehr viel Code da in anonyme Klasse verpackst. Ich muss gestehen, dass ich dazu tendiere, sofern man eben Java 7 verwenden kann, variante 2 mit einem Switch zu verwenden und die einzelnen Aktionen, sofern ausreichen viel zu tun ist, in einzelne Methoden packe.
 
Zu viele if/else Anweisungen werden unübersichtlich und auch wenn man an der Eventquelle etwas verändern muss.

Innere Klassen sind normalerweise übersichtlicher und entsprichen mehr dem OO-Design.
 
Es sei denn man ist durch die Struktur des Projektes gebunden.
Z.B. sagt MVC da eigentlich an, den Listener von der Gui zu trennen.
 
Was spricht gegen eine richtige Klasse !?
Ich hab hier in letzter Zeit zu diesem Thema immer nur Anonyme Klasse, Innere Klasse und halt die Implementierung in this vorgefunden.
Ich persönlich mag es aber, eigene Klassen zu schreiben Bsp. FileActionListener o.ä. und diese dann halt zuzuweisen.

Bin ich da so auf dem Holzweg? :autsch:

gruß Vanny
 
Na MVC würde dir da vermutlich sogar Recht geben. Und in MVC würde ich die Listener auch in (eine) eigene Klasse/n auslagern.
 
Was spricht gegen eine richtige Klasse !?
Ich hab hier in letzter Zeit zu diesem Thema immer nur Anonyme Klasse, Innere Klasse und halt die Implementierung in this vorgefunden.
Ich persönlich mag es aber, eigene Klassen zu schreiben Bsp. FileActionListener o.ä. und diese dann halt zuzuweisen.

Bin ich da so auf dem Holzweg? :autsch:

gruß Vanny
Ich persönlich finde anonyme Klassen mit jeweils maximal ~5 Zeilen Code am schönsten, ansonsten in eine Methode auslagern. Der Code steht genau bei dem Element welches ihn benutzt, und du brauchst keine unsinnigen/nichtsaussagenden Klassennamen für jeden einzelnen Listener erfinden. Aber das gilt natürlich nur wenn man denselben Listener nicht für mehrere Elemente verwenden will.
 
Das MVC Pattern besagt, dass ein Model, mehrere Views und ein Controller mehrere Views haben kann. Trygve/MVC
Leider ist das ganze 30 Jahre alt.
 
Zuletzt bearbeitet:
ich erstell mir auch lieber ne eigene Klasse, zum einen, weil ich die ganzen blabla$1.class dateien hässlich finde, und zum anderen dann der Code zum erstellen vom GUI übersichtlicher ist, wenn man lediglich
Code:
button.addActionListener(...);
schreiben muss, als wenn man da dann auch noch die actionPerformed() definiert und so weiter.
Aber was mich interessiert, ist das euch nicht ein Störfaktor, wenn diese $1,2,3.class dateien im Verzeichnis rumschwirren, oder bekommt man die eh nicht mit, weil ihr zB. alles in ne .jar packt?
 
ich erstell mir auch lieber ne eigene Klasse, zum einen, weil ich die ganzen blabla$1.class dateien hässlich finde, und zum anderen dann der Code zum erstellen vom GUI übersichtlicher ist, wenn man lediglich
Code:
button.addActionListener(...);
schreiben muss, als wenn man da dann auch noch die actionPerformed() definiert und so weiter.
Aber was mich interessiert, ist das euch nicht ein Störfaktor, wenn diese $1,2,3.class dateien im Verzeichnis rumschwirren, oder bekommt man die eh nicht mit, weil ihr zB. alles in ne .jar packt?

Mit ner guten IDE und nem Deployment-Skript können dir die .class Dateien vollkommen egal sein, ich persönlich hab glaub ich seit einiger Zeit garkeine mehr gesehen 😀

Mich würde mal interessieren wie du diese ganzen "nutzlosen" Klassen dann benennst?
 
Mit ner guten IDE und nem Deployment-Skript können dir die .class Dateien vollkommen egal sein, ich persönlich hab glaub ich seit einiger Zeit garkeine mehr gesehen 😀

Mich würde mal interessieren wie du diese ganzen "nutzlosen" Klassen dann benennst?

Ich tu dann natürlich au nicht für jeden Button eine eigene Klasse schreibn, sondern für eine Buttongruppe je einen und dann halt mit getSource() schon nochmal unterscheiden. Das ist zwar dann auch mit if oder switch, aber da hab ich dann keine ewig langen Abfragen. zB gibts bei mir dann einen MenuListener, der auf die Menubar und die start/pause/quit-Buttons aufpasst, und im Falle von zB. nem Memory-Spiel einen FieldListener, der auf die Karten im Spiel aufpasst.
 

Zurück
Oben