OnClickListener für mehrere Buttons

Wenn sie alle was Anderes machen ist es sinnvoller, jedem seinen eigenen OnClickListener zu geben.
Wenn sie alle dasselbe machen, ist es sinnvoller, ein und denselben OnClickListener zu benutzen.

Wenn sie alle dasselbe mit anderen Werten machen (Beispielsweise diese dusseligen Soundboards), ist es sinnvoll, ein und denselben OnClickListener zu benutzen und den Buttons die Werte, die anders sind, mitzugeben.
(Beispielsweise einen Standardbutton um einen String 'mediafile' erweitern und in der onClick eben diesen String auszulesen und an Hand dessen dann das Soundfile zu laden)

Da du mit if (wenn du es schon so machst, nimm vllt lieber switch case) arbeitest, gehe ich davon aus das die buttons jeweils unterschiedliche aktionen auslösen.
In diesem fall solltest du wirklich auch verschiedene click listener benutzen. Natürlich geht beides, aber deine Variante ist programmatisch nicht so sauber.

Ist es nicht eher so das es am Programmierstil liegt? Als ich java gelernt habe, war es sozusagen normal "<Klasse> implements ActionListener" zu benutzen und den jeweiligen Elementen dann einfach .setActionListener(this); zu geben.
mMn. hat das den Vorteil das man alle Actions zentral in einer Methode hat.

Als ich dann irgendwann mit Android angefangen hab, mit Tutorials usw. war ich erst mal total verwirrt warum denn die Leute z.B. 5 Buttons direkt nacheinander mit separaten Listenern versehen haben . Gehört anscheinend zum Programmierstil und nachdem ich mal, ich glaube sogar hier im Forum, nachgefragt habe konnte mir keiner wirklich sagen warum das so ist.

Wären wir noch in den Zeiten als nach "Lines of Code" bezahlt wurde, würde ich verstehen warum es sich so entwickelt hat.

Aber ich muss zugeben, das ich in Android auch eher die zweite Variante verwende, da man immer wieder mal ein Codeschnipsel aus dem Internet kopiert und es dort eben so gemacht wird

~ Doppelpost ~

Den beschriebenen Beitrag finde ich gar nicht.

Insofern versuche ich das hier zu erklären:
Wenn Du <Klasse> implements ActionListener machst, dann leitest Du eine neue Klasse ab, Du nutzt also die Vererbung.
Sagen wir, Du hast 9 unterschiedliche Buttons die das Gleiche tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle.

Sagen wir, Du Du hast 9 unterschiedliche Buttons die unterschiedliche Dinge tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle. In diesem Fall musst Du die einzelnen Button irgendwie unterscheiden können.
Oh, und ellenlange if Abfragen und switch Statements sind einerseits schwer zu lesen und andererseits schwer zu debuggen.

Du kannst natürlich jedem der Buttons eigene Implementierungen eines ActionListener geben. .setActionListener(new ersteButtonActionListener())
Damit legst Du für jede Aktion eine neue Klasse an.
Die Variante .setActionListener(new ActionListener () { onAction() {} } ) zentralisiert das Ganze in eine einzige Klasse, so dass Du eben keine 9 einzelnen Dateien herumfliegen hast.
Hier nutzt Du also nicht die Vererbung, sondern erstellst dynamisch konkrete Instanzen eines abstrakten Interface, die völlig unabhängig und losgelöst voneinander existieren.

Tutorials sind ja kein Produktivcode. Da wird Dir nur gezeigt wie etwas grob funktioniert. Die Konzepte richtig anzuwenden musst Du schon selbst lernen.

Die Frage, welche Variante man nimmt, hängt also immer davon ab, was genau man zu erreichen versucht.
Dazu könnte es hilfreich sein, die Vor- und Nachteile zu kennen.

Eigene Einzelklasse:
Pro:

• Kapselung
• Zentraler Zugriff
• Wiederverwendbar

Contra:

• Verleitet zur unübersichtlichen Verschachtelung bei Trennung der aufrufenden Objekte

Eigene mehrere Klassen:
Pro:

• Wiederverwendbar

Contra:

• Bei starker funktionaler Ähnlichkeit mehrere Dateien zu pflegen

Dynamisch erzeugte Objekte:
Pro:

• Schnell implementiert
• Leicht zu testen

Contra:

• Schlecht wiederverwendbar
• Verleitet bei ähnlicher Funktionalität zu doppeltem Code
• Schwer zu lesen

Man sieht also: Das beste Pro:Contra Verhältnis (3:1) hat die einzelne eigene Klasse.

Bei den meisten UI Implementierungen tun die 9 Buttons auch alle das Gleiche – nur halt mit unterschiedlichen Werten.
Alle spielen einen Sound ab – aber jeder einen Anderen. (SoundBoard)
Alle öffnen einen neuen Screen – aber jeder einen Anderen (Button-Navigation)
Alle tragen eine Ziffer in das Display ein – aber jeder eine Andere (Wähltasten, Taschenrechner, OnScreen Tastatur…)
Alle navigieren zu einer Seite – aber jeder zu einer Anderen. (Browsertasten: Zurück/Reload/Nächste)

Klar gibt es bei einigen UI unterschiedliche Aktivitäten pro Button, beispielsweise im Dateimanager Kopiere/Verschieben/Löschen.
Da sollten das dann eine Klasse pro Listener werden.

HTH

Zitat von Marco Feltmann

Dynamisch erzeugte Objekte:Pro:

Schnell implementiert

Leicht zu testen

Contra:

Schlecht wiederverwendbar

Verleitet bei ähnlicher Funktionalität zu doppeltem Code

Schwer zu lesen

Alles anzeigen

Also ich finde das die einzelnen Listener Objekte genauso gut wiederverwendbar sind wie eine einzelne Klasse.
Man ist wie deine überschrift schon sagt, mit dieser Variante einfach viel dynamischer. Außerdem ist es vom Programmierstil her einfach besser und die Listener befinden sich in der Regel immer in der dazugehörigen Layout Klasse.

Zitat von ChampS

Also ich finde das die einzelnen Listener Objekte genauso gut wiederverwendbar sind wie eine einzelne Klasse.

Dann erklär mir bitte mal, wie Du ein und denselben dynamisch generierten Listener drei unterschiedlichen Buttons zuweist.

Ich hab gerade die Android Syntax dafür nicht im Kopf, daher mach ichs mal an nem JavaFX Beispiel.
Kein Gewähr für richtige Parameter oder Bezeichnungen, es ist eher Pseudocode, aber das Prinzip wird hoffentlich klar.

private Button button = new Button();
private Button button2 = new Button();

private Eventhandler<ActionListener> listener = new Eventhandler<ActionListener>() {
@Override
public void handle(Event event) {
HIER STEHT DEIN CODE
}
};

button.setEventHandler(listener);
button2.setEventHandler(listener);

Damit legst Du eine Instanzvariable an. Ob die jetzt aus Deinem eingeschobenen Code kommt oder aus einer eigenen Datei ist ja egal.

In einem anderen ListView wirst Du da allerdings nicht mehr ran kommen.

1. Habe ich das so verstanden, dass es darum ging in einer Layoutdatei die einzelnen Listener zu setzen und welche Variante nun am elegantesten ist.

2. Wieso soll man diese Variable nicht weiterreichen können?