Mehrfachvererbung in dem Fall angemessen?

[DrGreenthumb]

Shade Of Mine schrieb:

bitte thread lesen

und tfas post lesen, der bringts auf den punkt

erst sagst du listener in java sind falsch, dann aber doch nicht weil es anonyme klassen gibt. Und jetzt ist es doch egal ob anonym oder nicht?

[Shade Of Mine]

DrGreenthumb schrieb:

erst sagst du listener in java sind falsch, dann aber doch nicht weil es anonyme klassen gibt. Und jetzt ist es doch egal ob anonym oder nicht?

Ich les dir gerne nochmal vor was ich geschrieben habe

weil sonst hast du sowas wie in java, dass du von zig millionen klassen erbst und denkst dass das so passt...
[...]
siehe java und listeners. vererbung ist hier falsch...

Danach kam die Frage wie man es sonst loesen kann und ich sagte

Java hat für sowas anonyme Klassen.

Ist eigentlich Java 101...
Oder haengst du dich gerade daran auf, dass die anonymen Klassen im Prinzip ja von den listener erben - dann empfehle ich mal einen Blick auf den Threadtitel: es geht um mehrfachvererbung.

[JustAnotherNoob]

@Shade:
versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

[vermutung]

JustAnotherNoob schrieb:

@Shade:
versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

Das weiß er glaub nicht mal selber.

[Shade Of Mine]

JustAnotherNoob schrieb:

versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

Ja, ist sehr verwirrend wenn ich von zig Millionen Klassen als parents spreche und dann Java Listeners als Beispiel bringe. Dazu muss naemlich schonmal Java Code gesehen haben um das zu verstehen...

[DEvent]

Shade Of Mine schrieb:

JustAnotherNoob schrieb:

versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

Ja, ist sehr verwirrend wenn ich von zig Millionen Klassen als parents spreche und dann Java Listeners als Beispiel bringe. Dazu muss naemlich schonmal Java Code gesehen haben um das zu verstehen...

D.h. du kritisierst die Praxis, dass die Hauptklasse immer von Listeners erbt, anstelle das man anonyme Klassen benutzt? Ok - Dann habe ich dich falsch verstanden.

[esel]

Shade Of Mine schrieb:

JustAnotherNoob schrieb:

versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

Ja, ist sehr verwirrend wenn ich von zig Millionen Klassen als parents spreche und dann Java Listeners als Beispiel bringe. Dazu muss naemlich schonmal Java Code gesehen haben um das zu verstehen...

versteh ich nicht ganz, was haben listener mit zu großen klassenhierarchien zu tun?
Klassenhierarchien mit "zig millionen" superklassen findet man eh nur in swing (und da beschränken sich die "zig millionen" auf sage und schreibe 5 (und die hat man auch in z.B. QT, das liegt eben in der natur der sache und ist auch nichts schlechtes). soviel dazu. wo genau liegt jetzt dein problem und was haben anonyme klassen mit dem ursprungsproblem (mehrfachvererbung) zu tun?

[esel]

DEvent schrieb:

D.h. du kritisierst die Praxis, dass die Hauptklasse immer von Listeners erbt, anstelle das man anonyme Klassen benutzt? Ok - Dann habe ich dich falsch verstanden.

nachtrag: dass man anonyme klassen (für listener oder sonstwas) benutzt ist im übrigen alles andere als praxis, jedenfalls in vernünftigem und/oder professionellem und/oder großem code/projekte. Üblicherweise benutzt man Actions für alle benutzereingaben, oder direkt eine binding api.

[tfa]

esel schrieb:

nachtrag: dass man anonyme klassen (für listener oder sonstwas) benutzt ist im übrigen alles andere als praxis, jedenfalls in vernünftigem und/oder professionellem und/oder großem code/projekte.

Anonyme Klassen sind selbstverständlich auch vernünftigem und/oder professionellem und/oder großem code/projekten gängige Praxis. Nichts spricht dagegen.

Üblicherweise benutzt man Actions für alle benutzereingaben, oder direkt eine binding api.

Wenn man genau hinsieht, stellt man fest, dass eine Action nichts anderes ist als ein Listener (bezogen auf Swing oder AWT). Bindings arbeiten intern ebenfalls damit - wie sollte es auch sonst gehen?

[byto]

esel schrieb:

versteh ich nicht ganz, was haben listener mit zu großen klassenhierarchien zu tun?

Sowas ist einfach schlechter Stil:

public class MyCustomTable extends JTable implements 
MouseListener, 
ComponentListener, 
FocusListener, 
KeyListener,
MouseMotionListener, 
HierarchyListener 
{ ... }

Die Listener werden in den meisten Fällen nur intern benutzt. Auf diese Weise werden sie aber Teil der öffentlichen Schnittstelle der Klasse. Jemand der die Klasse benutzt, könnte die Interface-Methoden von aussen aufrufen, was (i) sinnlos und (ii) nicht gewollt ist und im worst case Fehler verursacht.
Deswegen sollte man Komposition (anonyme, innere Klassen) statt Vererbung für sowas nutzen, ausser es ist aus OO-Sicht explizit notwendig, das die eigene Klasse vom Typ des Interfaces ist.

[+fricky]

^^blöd an den Listenern ist auch, dass man immer alle methoden implementieren muss, obwohl man nur die hälfte braucht. ich nehme lieber die xxxAdapter-klassen, da muss man's nicht tun.

[hustbaer]

Blöd an den Delegates ist dagegen wieder, dass man immer alle Funktionen einzeln verdrahten muss.
Bei Listener-Interfaces kann man sich die Granularität dagegen hübsch aussuchen
(EDIT: beim Definieren des Interface' meine ich - beim Implementieren des Interface muss man natürlich das "fressen", was man vorgesetzt bekommt /EDIT)

Ich finde beide Lösungen inetwa gleich elegant bzw. gleich hässlich.

[DrGreenthumb]

Shade Of Mine schrieb:

JustAnotherNoob schrieb:

versteh ich das richtig, dass du also nicht das Konzept Javas mit den Listenern in Frage stellst, sondern nur meinst dass man immer nur anonyme Klassen als Listener verwenden soll und nicht die eigentliche Klasse von Listeners erben lassen soll?
Wenn ja, dann hast dus ziemlich schlecht formuliert, wenn nein blick ich nicht was du meinst.

Ja, ist sehr verwirrend wenn ich von zig Millionen Klassen als parents spreche und dann Java Listeners als Beispiel bringe. Dazu muss naemlich schonmal Java Code gesehen haben um das zu verstehen...

Ja, ist wirklich verwirrend. Meinst du jetzt das Konzept von Listener, wie in Java, ist schlecht oder nicht?

Ich finde solche Listener-Klassen prinzipiell besser als Signale wie in GTK oder QT. Aber ein Nebeneffekt ist eben, dass man öfter von mehreren Interfaces erbt.

[byto]

Schlecht:

public class MyView extends JPanel implements MouseListener, MouseMotionListener, KeyListener, FocusListener {...}

Besser:

public class MyView extends JPanel {
  private MouseListener mouseListener;
  private MouseMotionListener mouseMotionListener;
  private KeyListener keyListener;
  private focusListener focusListener;
  ...
}

[Shade Of Mine]

DrGreenthumb schrieb:

Ich finde solche Listener-Klassen prinzipiell besser als Signale wie in GTK oder QT. Aber ein Nebeneffekt ist eben, dass man öfter von mehreren Interfaces erbt.

Du erbst nicht von listener. In ganz ganz ganz wenigen ausnahmefällen vielleicht... idR habe ich aber in Java Programmen keine listener-vererbung drinnen. Maximal dass eine Klasse von einem listener erbt. idR geht es aber über anonyme klassen.

@byto:
warum hast du die listener als member...?

[tfa]

Shade Of Mine schrieb:

Du erbst nicht von listener. In ganz ganz ganz wenigen ausnahmefällen vielleicht... idR habe ich aber in Java Programmen keine listener-vererbung drinnen. Maximal dass eine Klasse von einem listener erbt. idR geht es aber über anonyme klassen.

Nochmal was zur Begriffsklärung (in der Annahme, dass wir uns auf Java beziehen): Listener sind (normalerweise) Interfaces. Klassen erben niemals von Interfaces. Klassen implementieren Interfaces. Klassen erben nur von anderen Klassen. Interfaces können andere Interfaces erweitern, auch mehrfach.

warum hast du die listener als member...?

Ich nehme an, das ist nur ein Beispiel, um den Unterschied zur Implementierung der Hauptklasse zu zeigen. Ob das Listener-Objekt als Member abspeichern muss oder nicht hängt vom Anwendungsfall ab.

[esel]

tfa schrieb:

Anonyme Klassen sind selbstverständlich auch vernünftigem und/oder professionellem und/oder großem code/projekten gängige Praxis. Nichts spricht dagegen.

nein in der regel nicht, außer bei sowas wie einem "ok" knopf in dialogen o.Ä. Dagegen spricht: ewiges suchen nach dem tatsächlichen controller code der irgendwo zwischen 100ten zeilen gui code steht.

Üblicherweise benutzt man Actions für alle benutzereingaben, oder direkt eine binding api.

Wenn man genau hinsieht, stellt man fest, dass eine Action nichts anderes ist als ein Listener (bezogen auf Swing oder AWT). Bindings arbeiten intern ebenfalls damit - wie sollte es auch sonst gehen?[/quote]
hab ich was anderes gesagt? Es ging darum dass man keine anonymen klassen für sowas benutzt sondern stattdessen zum beispiel actions.

[tfa]

esel schrieb:

tfa schrieb:

Anonyme Klassen sind selbstverständlich auch vernünftigem und/oder professionellem und/oder großem code/projekten gängige Praxis. Nichts spricht dagegen.

nein in der regel nicht, außer bei sowas wie einem "ok" knopf in dialogen o.Ä. Dagegen spricht: ewiges suchen nach dem tatsächlichen controller code der irgendwo zwischen 100ten zeilen gui code steht.

Schon schlimm, wenn man sich in seinem Code nicht zurechtfindet. Aber was hat das mit anonymen Klassen zu tun?

private Action fooAction;

public Action getFooAction() {
	if (fooAction==null) {
		fooAction = new AbstractAction("Meine tolle Foo-Action") {

			@Override
			public void actionPerformed(ActionEvent e) {
				service.fooService();				
			}};
	}
	return fooAction;
}

Es ging darum dass man keine anonymen klassen für sowas benutzt sondern stattdessen zum beispiel actions.

Das eine schließt das andere doch nicht aus. Siehe oben. (Reden wir über die selben anonymen Klassen?)

[esel]

tfa schrieb:

esel schrieb:

tfa schrieb:

Anonyme Klassen sind selbstverständlich auch vernünftigem und/oder professionellem und/oder großem code/projekten gängige Praxis. Nichts spricht dagegen.

nein in der regel nicht, außer bei sowas wie einem "ok" knopf in dialogen o.Ä. Dagegen spricht: ewiges suchen nach dem tatsächlichen controller code der irgendwo zwischen 100ten zeilen gui code steht.

Schon schlimm, wenn man sich in seinem Code nicht zurechtfindet. Aber was hat das mit anonymen Klassen zu tun?

soll auch projekte geben an denen mehr als eine person arbeitet.
davon abgesehen hab ich auch nicht ständig überblick wo jede einzelne funktion in meinem code versteckt ist, tolle tools wie call graph generation gibt es ja nicht umsonst.
es geht darum dass man gui code nicht mit controller code zumüllt, sondern die teile trennt, dann findet man sie auch einfacher wieder. gilt jetzt auch nicht nur für benutzer actions...

private Action fooAction;

public Action getFooAction() {
	if (fooAction==null) {
		fooAction = new AbstractAction("Meine tolle Foo-Action") {

			@Override
			public void actionPerformed(ActionEvent e) {
				service.fooService();				
			}};
	}
	return fooAction;
}

Es ging darum dass man keine anonymen klassen für sowas benutzt sondern stattdessen zum beispiel actions.

Das eine schließt das andere doch nicht aus. Siehe oben. (Reden wir über die selben anonymen Klassen?)

na wer actions so benutzt hat eh shcon verloren

[tfa]

esel schrieb:

soll auch projekte geben an denen mehr als eine person arbeitet.
davon abgesehen hab ich auch nicht ständig überblick wo jede einzelne funktion in meinem code versteckt ist, tolle tools wie call graph generation gibt es ja nicht umsonst.
es geht darum dass man gui code nicht mit controller code zumüllt, sondern die teile trennt, dann findet man sie auch einfacher wieder. gilt jetzt auch nicht nur für benutzer actions...

"Call Graph"? GUI-Code? Controller Code? Zumüllen? Wie kommst du jetzt schon wieder da rauf?
Du hast gesagt, dass anonyme Klassen schlecht sind. Warum? Bleib bei der Sache!
Ich glaube, du weißt nicht so recht, worüber du redest....

na wer actions so benutzt hat eh shcon verloren

Bei uns (ein Projekt mit vielen 100 Zeilen Code und vielen, vielen Entwicklern, die sich alle auskennen) benutzen wir Actions u.a. so. Wo ist das Problem?
Zeigt doch mal, wie du das machst, Schlauberger!