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



## Jack159 (3. Jul 2012)

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:

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


oder mit dieser if-Abfrage:

```
//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
		}

	}
```


----------



## njans (3. Jul 2012)

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.


----------



## StableElectron (3. Jul 2012)

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.


----------



## njans (3. Jul 2012)

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.


----------



## vanny (3. Jul 2012)

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


----------



## njans (4. Jul 2012)

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.


----------



## Schandro (4. Jul 2012)

vanny hat gesagt.:


> 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.
> 
> ...


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.


----------



## bERt0r (5. Jul 2012)

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.


----------



## raGe666 (5. Jul 2012)

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 
	
	
	
	





```
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?


----------



## vanny (5. Jul 2012)

raGe666 hat gesagt.:


> ... oder bekommt man die eh nicht mit, weil ihr zB. alles in ne .jar packt?



Naja, es ist schon ratsam, die Veröffentlichung möglichst schmal zu halten.
Liegt natürlich bei dir und deinem Projekt, wie du damit umgehst.


----------



## njans (5. Jul 2012)

Hmm also ich sah noch nie das Problem mit zu vielen Class fiels. In einer jar sieht man die nicht


----------



## Schandro (5. Jul 2012)

raGe666 hat gesagt.:


> 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
> 
> 
> 
> ...



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?


----------



## raGe666 (6. Jul 2012)

Schandro hat gesagt.:


> 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.


----------

