Wir hatten eine Diskussion über die beste Vorgehensweise für die Verwendung von Listenern in Java: Ob die Listener-Logik in der anonymen Klasse bleiben sollte oder ob sie in einer separaten Methode sein sollte, zum Beispiel:
%Vor%oder
%Vor%Was ist der empfohlene Weg in Bezug auf Lesbarkeit und Wartbarkeit? Ich bevorzuge es, den Code im Listener zu behalten und nur wenn er zu groß wird, mache ich ihn zu einer inneren Klasse. Hier gehe ich davon aus, dass der Code nirgendwo anders dupliziert wird.
Danke.
Meine selbst auferlegte Regel ist:
Ziemlich einfach, leicht zu folgen und produziert mehr oder weniger lesbaren Code. Aber dann muss ich zugeben, dass ich nie daran gedacht habe, was dein Beispiel zeigt.
Diese Frage wird hier teilweise beantwortet:
Gibt es eine bessere Praxis für Zuhörer
Ich mag auch den anonymen Weg aus zwei Gründen nicht:
1) Sie können den Code nicht so einfach wiederverwenden, so dass Sie nach einiger Zeit möglicherweise doppelten Code haben. 2) Ich finde, dass es das Lesen des Codes unterbricht (andere stimmen nicht überein ... persönlicher Geschmack). Ich denke, jeder würde zustimmen, dass wenn Sie mehr als 5-10 Zeilen machen, dass eine anonyme innere Klasse keine gute Idee ist (ich würde sagen, mehr als 2 ist zu viel).
Meiner persönlichen Meinung nach kommt es darauf an. Wenn der Listener nur zu einer einzelnen Komponente hinzugefügt werden soll, sehr einfach ist und ein integraler Bestandteil der GUI ist, dann würde eine anonyme innere Klasse gut funktionieren. Wenn der Listener komplex ist, wird er zu mehreren Komponenten hinzugefügt, hat seinen eigenen separaten Status, dann ist eine separate eigenständige Klasse besser. Dazwischen ist die private innere Klasse. HTH.
Bearbeiten: Mein schlechtes. Ich habe eine andere Frage beantwortet - ob ich eine separate Stand-alone-Klasse für einen Zuhörer verwenden soll oder nicht. Um zu entscheiden, ob ein interner Klassencode in einer Methode beibehalten werden soll, stimme ich dem anderen zu, dies hängt von der Größe und Komplexität des Listener-Codes ab.
Wenn auf die Methode buttonPressed() immer von etwas abgesehen von der anonymen inneren Klasse zugegriffen werden muss, verwenden Sie eine Methode. Andernfalls wird der Code einfach in actionPerformed() eingefügt.
In meiner persönlichen Erfahrung ist es am besten, dem MVC-Muster zu folgen. Auf diese Weise gibt es eine separate Klasse, die ein Modell darstellt, das alle relevanten Aktionen, Aktionslistener usw. erzeugt. Es ist vorzuziehen, dass Aktionen als endgültige Klassenfelder dargestellt werden, die im Konstruktor instanziiert werden.
Zum Beispiel:
%Vor%Die Ansicht wird auch durch eine separate Klasse repräsentiert, die das Modell als Konstruktorparameter verwendet, wo die eigentliche Schaltflächeninstanziierung stattfindet. Zum Beispiel:
%Vor%Mit diesem Ansatz ist es sehr praktisch, die Logik von actionPerformed als Teil der anonymen Klasse zu implementieren, da sie nur sehr wenig wiederverwendet werden kann. Die gesamte Logik ist in den Controller eingekapselt, so dass die Aktionen wirklich als Wrapper um den Controller-Aufruf dienen, der als Modell für eine Schaltfläche verwendet werden kann.
Ja, es hängt sehr davon ab, was Sie tun wollen. Ich denke, dass anonyme innere Klassen wegen zweier Mythen einen schlechten Ruf bekommen haben. Man kann anonymen Code nicht wiederverwenden. Und zwei, Speicherlecks. Aber diese sind leicht mit einem einfachen Ansatz zu beheben. Speichern Sie einen Verweis auf die Instanz. Zum Teilen von Code erstellen Sie einfach einen Verweis auf die anonyme innere Klasse.
%Vor%Jetzt können Sie diese Aktion für mehrere Komponenten wiederverwenden. Für das spätere Problem der Speicherlecks können Sie diesen Verweis verwenden, um die Registrierung aufzuheben, oder die zweite und einfachere Option ist WeakListeners. WeakListeners haben den Vorteil, dass sie nicht mehr nach ihrer Erstellung verwaltet werden müssen.
Was Stil anbelangt, so finde ich anonyme Listener recht praktisch und in manchen Fällen einfacher zu lesen, wenn es um das Threading in Swing geht, weil es den Code in einer Methode hält (invokeLater, executeInBackground, usw.). Wenn Sie anon-Listener an eine Instanzmethode delegieren, trennen Sie den Code, bei dem Sie nicht lesen können, was vor dem Listener passiert ist, und die Logik, die dem Listener zugeordnet ist, auf einem Bildschirm. Sie neigen dazu, getrennt zu werden, und es ist schwieriger zu folgen.
Es ist etwas zu beachten, wenn Sie ActionMaps verwenden, werden die meisten Speicherlecks mit dem Tastaturhören weggehen. Leider sind Dinge wie Fokus-Listener oder Listener, die bei zentralen Systemen registriert sind, immer noch ein Problem. (Auch hier sind WeakListeners super). Und Sie haben bereits einen Platz, um die Aktion mit jeder Komponente zu halten, so dass Sie keine zusätzlichen Instanzvariablen erstellen müssen, um sie zu speichern. Wenn Sie über zwei Komponenten (z. B. in einer Menüleiste und in einem Steuerelement) wiederverwendet werden müssen, erstellen Sie eine separate Klasse.
Tags und Links java swing listener anonymous-class