Viele anfänger kennen das: Man implementiert mouselistener, mousemotionlistener, uuund so weiter und so fort - und hat direkt einen haufen von listenern.
Auch 5 Adapter sind meiner meinung nach nicht die lösung wenn man 5 listener braucht.
Nun habe ich das wie folgt gemacht:
einfach eine klasse ListenerCollection die alles mögliche implementiert. (so 10 - 15 sachen) Ich brauche zwar nicht alle methoden, aber ich würd halt gern bei listenern bleiben.
Ist das so “schlecht” programmiert?
Jetzt mache ich halt einfach folgendes:
ListenerCollection listenerColx = new ListenerCollection();
component.addComponentListener(listenerColx);
component.addMouseListener(listenerColx);
component.addMouseMotionListener(listenerColx);
component.addKeyListener(listenerColx);
/** und so weiter und so fort, wenn ich einem projekt wirklich mal alles mögliche brauche. **/
Würde das bei einem “ok-programmiert-oder-nicht-test” durchgehen?
Du programmierst eine einzige Listener Klasse und muss in den relevanten Methoden prüfen, welches der Objekte, denen Du die Listener-Instanz zugewiesen hast, das Ereignis tatsächlich ausgelößt hat. Dass führt schnell zu langen if .. else if-Kaskaden.
Außerdem ist die Aktion, die der Listener ausführen soll immer sehr eng mit der Klasse verbunden, in der das auslösende Objekt erzeugt wird. Bei Deinem Ansatz verteilst Du den fahlich zusammehängenden Code auf verschiedene Klassen, die in der Projektstruktur nicht in erkennbarem Zusammenhang stehen.
Im Allgemeinen ist es empfehlenswert, Listener als anonyme Klasse für genau ein Auslöser-Objekt zu Programmieren (oder als anonyme Ableitung eines Adpters*).
*) Adapter meint hier die Implemendierung eines Interface mit leeren Methoden, nicht einen Adapter im Sinne der Entwurfspattern.
Es stimmt, der Overhead für zig Listener ist nervig. Aber so eine ListenerCollection ist trotzdem nicht die Lösung. Ich empfehle etwas Geduld, denn mit Java 8 bleibt davon nicht mehr viel übrig: myButton.addActionListener(e -> tuWas());
Also ich finde das Konzept einer ListenerCollektion prinzipell nicht verwerflich. Ich weis nicht wo da eine Menge if/else Verzweigungen sein sollen, die Klasse hat eben eine actionPerformed und eine keyPressed Methode, die wird aufgerufen. Kein If (event instanceof ActionEvent) oder dergleichen notwendig. Aus der Sicht der Architektur finde ich so eine Klasse per se aber hässlich. Da sollte wenn schon auch ein Sinn dahinter sein, der diese ganzen Listener miteinander verbindet. Mithilfe dieses Sinns kann man der Klasse dann auch einen besseren Namen als ListenerCollection geben, das ist nämlich dann sehr verwirrend wenn du ein paar dieser ListenerCollections hast
Das wird natürlich alles komplett rückwärtskompatibel sein. Und in dieser Form funktioniert das ohnehin erstmal NUR für Listener (bzw. Typen allgemein) die genau eine abstrakte Methode haben. (Wurden deswegen auch mal eine Weile als “SAM-Types” bezeichnet: “Single Abstract Method Type”).
Da ich persönlich in solchen Fällen aber ohnehin versuche, diesen Typ nur als “Verbindung” zwischen einer Stelle und einer anderen Stelle anzusehen, wird diese Schreibweise da einiges vereinfachen. Konkret meine ich mit “Verbindung” dass man z.B. bei einem ActionListener (wenn man nicht sowieso Actions verwendet - und eben bei anderen SAM-Types) in die Implementierung dieser einen abstrakten Methode im Idealfall NUR den Aufruf einer einzelnen, privaten Methode schreiben sollte. Und wenn man die Wahl hat zwischen
gefällt mir das zweite doch besser (auch wenn ich gerade wieder schmerzlich bemerkt habe, dass ich mir endlich mal Java 8 runterladen muss, weil ich die genaue Syntax immernoch nicht drin habe)
