Eventhandler: innere Klassen vs. "normale Klassen"

AKST

Erfahrenes Mitglied
Hallo Leute,

ich als Java-Anfänger frage mich folgendes:

Wie bevorzugt ihr eure z.B. ActionListener umzusetzen. Mit (anonymen) Inneren Klassen oder normalen Klassen.

Ich finde normale Klassen (implements ActionListener) viel übersichtlicher auch wenn man dieser im Konstruktor das jeweilige Fenster übergeben muss.
Ich frage deshalb, weil ich es oft in Büchern, in Foren oder bei Gui-Buildern sehe, dass innere Klassen verwendet werden.
Ich finde diesen Programmierstil aber unschön.
 
Zuletzt bearbeitet:
Moin,
ich halte eine eigene, von ActionListener abgeleitete Klasse oder auch eine implementierende Klasse für unpraktisch. Zumindest kenne ich keinen Fall, wo es Sinn macht. Grund: Es wird lediglich die Methode actionPerformed() implementiert. Und ich sehe keinen Sinn, warum nicht genau das Objekt bzw. die Komponente, die reagieren soll, eine eigene actionPerformed() bekommen sollte. Nimmst Du hingegen ein Frame mit verschiedenen Komponenten als ActionListener, musst Du jedes Mal zunächst herausfinden, welche Komponente das Event ausgelöst hat.
 
Original geschrieben von AKST

Wie bevorzugt ihr eure z.B. ActionListener umzusetzen. Mit (anonymen) Inneren Klassen oder normalen Klassen.

Das kommt auf die Situation, grösse des Projektes, usw an.


Ich frage deshalb, weil ich es oft in Büchern, in Foren oder bei Gui-Buildern sehe, dass innere Klassen verwendet werden.
Ich finde diesen Programmierstil aber unschön.

In Bücher kommt das fast immer so vor, weil Listener das Paradebeispiel ist um dem Leser den Gebrauch von anonymen Klassen beizubringen.
 
Übrigens noch eine Ergänzung:
Anonyme Klassen sind etwas anderes als innere Klassen!
Nicht dass hier Verwechslungen aufkommen.
 
@Snape,

es stimmt zwar, dass eine anonyme Klasse für einen ActionListener oft nur die Methode actionPerformed() besitzt wenn ich in dieser aber etliche Actions von ettlichen Buttons und Menüitems über getActioncommand abfragen muss, dann sieht der Code meiner Meinung nach ziemlich unsauber aus.
Ich könnte natürlich in dieser Methode das ActionEvent an eine andere Methode weitergeben und dort alles managen, dann wäre der Actionlistener wirklich klein.
 
Original geschrieben von AKST
Ich könnte natürlich in dieser Methode das ActionEvent an eine andere Methode weitergeben und dort alles managen, dann wäre der Actionlistener wirklich klein.
In dem Fall ist es besser, wenn die Klasse, wo Du den ActionListener brauchst selbst der ActionListener ist und implementiert die Methode actionPerformed().
 
Original geschrieben von AKST
@Snape,

es stimmt zwar, dass eine anonyme Klasse für einen ActionListener oft nur die Methode actionPerformed() besitzt wenn ich in dieser aber etliche Actions von ettlichen Buttons und Menüitems über getActioncommand abfragen muss, dann sieht der Code meiner Meinung nach ziemlich unsauber aus.
Ich könnte natürlich in dieser Methode das ActionEvent an eine andere Methode weitergeben und dort alles managen, dann wäre der Actionlistener wirklich klein.

MenuItems und Buttons die die selbe Funktionalität besitzen (z.b Speichern) sollten auch ein Object der selben klasse als Listener nutzen.
 
Jo, und unübersichtlich wird das nicht, wenn Du jeder Komponente einen eigenen ActionListener verpasst.

Code:
		jbOK.addActionListener(new java.awt.event.ActionListener()
		{
			public void actionPerformed(ActionEvent e)
			{
				jbOK_actionPerformed(e);
			}
		});
		jbCancel.addActionListener(new java.awt.event.ActionListener()
		{
			public void actionPerformed(ActionEvent e)
			{
				jbCancel_actionPerformed(e);
			}
		});

usw.
 
Hmm, vielleicht habeb wir uns ja missverstanden. Ich meine es so, wenn ich ein JFrame habe auf dem sich ca. 10 Buttons befinden, dann habe ich für dieses JFrame nur einen Actionlistener und füge jedem Button diesen ActionListener hinzu.

Wenn ich nun statt einer "normalen Klasse" eine anonyme Klasse verwende, dann müsste ich für jeden Button das ActionCommand abfragen, was ich etwas unübersichtlich finden würde, da die anonyme Klasse versetzt mitten im Quellcode des JFrames sitzt.
Deshalb meinte ich, dass ich in der actionPerformed-Methode nur eine Methode (z.B.: "events_managen(event)") aufrufe und dieser das ActionEvent übergebe. In dieser Methode würde ich dann alle Actioncomands in if-Blöcken abfragen und bearbeiten.

Wäre das unsauber?
Ist überhaupt etwas daran auszustezen wenn ich immer nur einen Actionlistener pro Frame nehme und anhand des ActionCommands das aufrufende Oberflächenelement identifiziere?
 
Zuletzt bearbeitet:
Original geschrieben von AKST

Wäre das unsauber?
Ist überhaupt etwas daran auszustezen wenn ich immer nur einen Actionlistener pro Frame nehme und anhand des ActionCommands das aufrufende Oberflächenelement identifiziere?

Ja sehr unsauber.

Du müsstest für jede Änderrung an einem Button eine Klasse editieren die du für alle anderen auch nutzt.

Was stört dich daran jede Aktion in einer eigenen Klasse zu kapseln?

Wenn du dann eine Aktion umändern willst brauchst du nur jene Klasse austauschen und nicht noch in einer Methode rumwurschteln.
 
Zurück