JAVA: ActionListener für mehrere Buttons in seperater Klasse

[Hardwaretoaster]

Ich arbeite mich gerade etwas in GUIS mit Java ein und stehe da vor einer Frage: Wie setze ich geschickt mehrere Buttons mit einen ActionListener Objekt um?

Aktuelle Situation:
-Klasse mit der GUI, kennt das Event-Objekt (wird auch von deren Kosntruktor angelegt) mit mehreren Buttons
-Event-Klasse, bekommt alsm Referenz die GUI-Klasse, jetzt wollte ich folgendendes machen:
if(e.getSoruce().equals(refrenz.button1){
//Aktion für Button 1, usw
}
Dazu müsste ich aber den Button public oder mindestens im package sichtbar machen.

Kann man das so machen oder gibt es da eine elegantere Lösung (die nach Möglichkeit nicht zu kompliziert umzusetzen ist)?

[Ganon]

Dem Schalter ein ActionCommand geben und dann mit e.getActionCommand fragen, welcher Schalter das ist :D

[Trap]

Normalerweise macht man das mit ActionListenern nicht.

Der NetBeans GUI-Builder erzeugt für jeden Button einen eigenen ActionListener, der dann die richtige Funktion aufruft:
jButton3.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton3ActionPerformed(evt);
}
});

[Hardwaretoaster]

Hm, muss die GUI leider von Hand machen, auch wenn ich mir für die nächsten Sachen den GUI-Designer von Netbeans (wird ja in letzter Zeit ziemlich gelobt) mal anschauen werde.

Werde wohl erstmal Ganons weg nutzen.

Wie sieht das aus, wenn ich von den EventHandlern aus auf der GUI maipulieren will? direkt oder gibt es da auch was Besseres? Komme ich da mit Observer weiter/ist das eleganter?

[del_4901]

Komme ich da mit Observer weiter/ist das eleganter?
Kommt drauf an, was du machen willst, manchmal sind zuviele Pattern auch gar nicht so toll. Es kann auch sein, das ein Mediator oder Anderes besser geeignet währe. Das kann man so nicht sagen, das merkt man aber spätestens beim Refactorn.

[Hardwaretoaster]

Das Problem ist folgendes: Ich habe noch arg wenig Ahnung von "richtigem" Software-Engineering, merke aber gerade bei der Programmierübung, dass es gar nicht ungeschickt wäre, sowas zu wissen.
Naja, vielleicht mache ich es auch erst mal über Package-Visibility, da packt ja außer mir niemand was in das Package udn außen ist es nicht sichtbar.

[Ganon]

Also naja, ich kann den NetBeans GUI-Builder nicht empfehlen, sofern die GUI komplexer wird. Will man an der etwas anpassen, darf man zu teilen das ganze Layout neu machen, weil der alles zerkloppt.

[Monger]

Also, es macht wenig Sinn, mehrere Buttons - die ganz unterschiedliche Funktion haben - auf den selben Listener umzuleiten, nur um dort dann wieder eine aufwendige Fallunterscheidung zu machen. Das ist hässlich, schwer wartbar, und fehleranfällig. Was passiert z.B. , wenn sich noch ein Button bei deinem Listener anmeldet, den du aber nicht kennst?

Sauberer ist es, den Listener völlig von dem zu isolieren was ihn aufruft. Und wenn du 20 verschiedene Verhaltensweisen hast, musst du halt auch 20 verschiedene Listener implementieren.

[Ganon]

Oder man nimmt ein schickes Application-Framework. Im Swing Application Framework von NetBeans packt man an eine Routine einfach ein @Action und sagt dann dem Schalter nur setAction(getAction(<Methodenname>)).

Ist noch etwas eleganterer ^^

[Monger]

Außerdem erlaubt Java ja auch anonyme Klassen, so dass ein Event Handler direkt im Aufruf geschrieben werden kann. Viel schneller und sauberer geht's eigentlich nicht mehr.

Anonyme Klassen und die komplexen Enumerationen sind im übrigen auch die beiden Punkte, die mir in .NET am meisten fehlen! :D

[Hardwaretoaster]

Ok, das mit den ananoymen Klassen werde ich mir mal anschauen.
Alles kan schön viele Möglichkeiten, die man hat und durchdenken muss...

[Bietchiebatchie]

Anonyme Klassen und die komplexen Enumerationen sind im übrigen auch die beiden Punkte, die mir in .NET am meisten fehlen! :D
:|
Dafür hat .net seit 1.0 events... und events sind jawohl deutlich eleganter für "event handling" als anonyme Klassen.

[Monger]

:|
Dafür hat .net seit 1.0 events... und events sind jawohl deutlich eleganter für "event handling" als anonyme Klassen.

Anonyme Klassen könnte man aber auch für andere Dinge ganz gut gebrauchen. Eben immer dann, wenn man mal fix ein Interface implementieren will, ohne dafür wieder gleich eine benamste Klasse aufzumachen.

Das ist unter Java insgesamt wohl etwas interessanter, weil sie (meinem Gefühl nach) im Java Standardframework deutlich stärker mit Interfaces arbeiten als in .NET .

Es gibt halt so ein paar Features, die ich persönlich in .NET gerne sehen würde. Der Check auf Exceptions zur Compile Zeit, zum Beispiel. Aber das ist halt meine Meinung, du musst ja nicht den selben Geschmack haben! ;)