multiple inheritance - irgendwann?

[AlArenal]

Ich sags mal ketzerisch so:

Es juckt weder meinen Chef (und damit meinen Gehaltsscheck) noch unsere Kunden, ob Java MI kann oder nicht. Mich störts auch nicht, weil ich keinen Anwendungsfall sehe, in dem MI der eleganteste und tollste Weg wäre, so ganz ohne unerwünschte Nebeneffekte.

Ich wüsste ja gerne was du da so entwickelst.. (außer Kreis, Rechteck, ..)

 

[kudi82]

Ooops.. Ich wollte noch was zum Artikel schreiben:
Da verstehe ich nun aber nicht wieso Collection besser ein Interface ist als eine Klasse?

Ich wüsste ja gerne was du da so entwickelst.. (außer Kreis, Rechteck, ..)

Wenn das Fundament nicht stimmt...

 

[stev.glasow]

Was sollte die Klasse Collection den implemtieren? Methoden wie add(), iterator() etc, müsste ich dann doch mit nem leeren Body versehnen oder abstarkt machen.

 

[Beni]

Stell dir eine Liste, basierend auf einem Array, und eine Menge, basierend auf einem Baum vor. Beide implementieren Collection.

Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?

 

[AlArenal]

Wenn du deine Signaturen auf Basis von Interfaces definierst, bist du unabhängig von der benutzten Implementation. Es gibt eine ganze Reihe von Klassen, die das Interface Collection oder List, o.ä. implementieren, die haben alle je nach Verwendung ihre Vor- und Nachteile.

Erwarten meine Methoden ein Interface, wird alles entgegen geniommen, was dieses Interface implementiert und ich kann an einer einzigen Stelle später von einer Klasse auf ne andere wechseln (weil sie flotter ist, weniger Speicher braucht, thread-sicher ist, ...), wenn diese dasselbe Interface implementiert.

Würde ich überall ne Abhängigkeit von einer bestimmten Klasse schaffen, hätte ich bei einer solchen Änderung je nach Umfang der Anwendung reichlich Aufwand, überall die Signaturen, Doku, etc. zu ändern...

 

[kudi82]

Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?

Nun, ich kann eine abstrakte Klasse machen, und dann habe ich dasselbe wie bei einem Interface. Das zeigt aber keinen Vorteil von Interfaces gegenüber Klassen. Das ist nur anders benennt, wenn ich das jetzt richtig verstanden habe. Und falls ja, da es in Java sowieso auch abstrakte Klassen gibt, wieso dann sich auch noch mit Interfaces herumschlagen, wenn sie im Prinzip nichts anderes machen.

 

[byte]

arbeiten mit interfaces bringt den vorteil, dass du dich nicht auf eine implementierung festlegen musst.

beispiel: interface List aus dem collection framework (die wahl der implementierung, also z.b. ArrayList oder Vector, bleibt offen und flexibel).

 

[stev.glasow]

Wenn du deine Signaturen auf Basis von Interfaces definierst, bist du unabhängig von der benutzten Implementation. Es gibt eine ganze Reihe von Klassen, die das Interface Collection oder List, o.ä. implementieren, die haben alle je nach Verwendung ihre Vor- und Nachteile.

Erwarten meine Methoden ein Interface, wird alles entgegen geniommen, was dieses Interface implementiert und ich kann an einer einzigen Stelle später von einer Klasse auf ne andere wechseln (weil sie flotter ist, weniger Speicher braucht, thread-sicher ist, ...), wenn diese dasselbe Interface implementiert.

Würde ich überall ne Abhängigkeit von einer bestimmten Klasse schaffen, hätte ich bei einer solchen Änderung je nach Umfang der Anwendung reichlich Aufwand, überall die Signaturen, Doku, etc. zu ändern...

Er wollte wissen warum Collection keine Klasse ist, mit Mehrfachvererbung und "leeren" Methoden hätte das eigentlich
den gleichen Effekt wie mit dem Interfaces Collection.

 

[AlArenal]

Bzw. meine Methoden können auch mit Instanzen unterschiedlicher Klassen gleichzeitig umgehen, sofern diese das passende Interface implementieren.

Wäre Shape ein Interface und würden Circle und Triangle dieses Interface implementieren, bräuchte ich nur eine Methode resize(Shape shape, Dimension dim), die für beide Klassen (und jede beliebige andere, die Shape implementiert) funktioniert..

 

[stev.glasow]

Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?

Nun, ich kann eine abstrakte Klasse machen, und dann habe ich dasselbe wie bei einem Interface. Das zeigt aber keinen Vorteil von Interfaces gegenüber Klassen. Das ist nur anders benennt, wenn ich das jetzt richtig verstanden habe. Und falls ja, da es in Java sowieso auch abstrakte Klassen gibt, wieso dann sich auch noch mit Interfaces herumschlagen, wenn sie im Prinzip nichts anderes machen.

Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden, wurde glaube ich in nem Post weiter obern erklärt

 

[Bleiglanz]

Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?

Nun, ich kann eine abstrakte Klasse machen, und dann habe ich dasselbe wie bei einem Interface. Das zeigt aber keinen Vorteil von Interfaces gegenüber Klassen. Das ist nur anders benennt, wenn ich das jetzt richtig verstanden habe. Und falls ja, da es in Java sowieso auch abstrakte Klassen gibt, wieso dann sich auch noch mit Interfaces herumschlagen, wenn sie im Prinzip nichts anderes machen.

schön langsam kommst du dahinter...

gerade weil es in Java keine MI gibt (und man also immer nur von EINER Klasse erben kann) braucht man einen Mechanismus, um die "Schnittstelle" einer Klasse von Ihrer eigentlichen Implementierung zu trennen

schau dir mal die Interfaces in java.util. an: Collection, Set, usw., veilleicht kommst du dann drauf wozu die gut sind, oder denk einfach an

java.lang.Comparable

wie sollte das mit abstrakten Klassen gelöst werden?

 

[kudi82]

Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden, wurde glaube ich in nem Post weiter obern erklärt

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

 

[Beni]

Er wollte wissen warum Collection keine Klasse ist, mit Mehrfachvererbung und "leeren" Methoden hätte das eigentlich den gleichen Effekt wie mit dem Interfaces Collection.

Da hast du völlig recht. Allerdings würde man dann wieder Mehrfachvererbung benötigen, damit alles schön funktioniert. Jetzt dreht man sich im Kreis, die Entwickler von Java entschieden sich schliesslich für Interfaces als eine Art "kastrierte MI".

Persönlich finde ich das keine schleche Idee. Wenn man ein Interface vor sich sieht kann man wirklich sicher sein, dass man nur diese Ding implementieren muss, und dann wird "es" schon funktionieren. Bei Vererbung bleibt die Unsicherheit, ob es nicht doch irgendwann eine zusätzliche Methode/Variable geben wird, die alle beachten sollten.

 

[AlArenal]

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

Ist nicht zulässig und führt zum Fehler beim Kompilieren, bzw. bei ner guten IDE schon vorher

 

[kudi82]

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

Ist nicht zulässig und führt zum Fehler beim Kompilieren, bzw. bei ner guten IDE schon vorher

Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...

 

[bygones]

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

Ist nicht zulässig und führt zum Fehler beim Kompilieren, bzw. bei ner guten IDE schon vorher

Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...

du erbst nicht von Interfaces. Man kann nur von Klassen erben. Man implementiert ein Interface. Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...

 

[Beni]

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

Dann hast du ein grosses Problem. Wenn du sehr viel Glück hast, machen "beide" Methoden dasselbe, und du kannst dich noch durchmogeln, wenn du Pech hast... Der "renaming"-Mechanismus von Eiffel hat schon was :wink:

Praktisch hingegen tritt das Problem (fast) nie auf. (Man kann es absichtlich herbeiführen um Code zu sparen, aber das ist ein anderes Thema).
Es gibt sooo viele Signaturen für Methoden, da trifft man sich halt selten.

[Edit: mit inneren Klassen und Delegates (schon wieder) kann man das Problem auch umgehen]

 

[stev.glasow]

Er wollte wissen warum Collection keine Klasse ist, mit Mehrfachvererbung und "leeren" Methoden hätte das eigentlich den gleichen Effekt wie mit dem Interfaces Collection.

Da hast du völlig recht. Allerdings würde man dann wieder Mehrfachvererbung benötigen, damit alles schön funktioniert. Jetzt dreht man sich im Kreis, die Entwickler von Java entschieden sich schliesslich für Interfaces als eine Art "kastrierte MI"...

Ganz deiner Meinung

Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden ...

 

[AlArenal]

Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...

Der Punkt geht an dich. Habs eben ausprobiert und du liegst richtig

Dennoch empfinde ich es ad hoc als stilistisches Pfui, ohne mir über weitergehende Konsequenzen Gedanken gemacht zu haben.

 

[kudi82]

Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...

Da hätte ich jetzt aber genau erwartet, dass Java dann diese sozusagen automatisch merged, da sie ja im Gegenteil zu einer Klasse, nicht schon implementiert sein können, und ich daher nicht bestimmen muss, welche Implementierung gewählt werden soll.

 

[stev.glasow]

Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)

Ist nicht zulässig und führt zum Fehler beim Kompilieren, bzw. bei ner guten IDE schon vorher

Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...

jop. Wenn man 2 Interfaces die eine gleiche Methode beschreiben implementiert juckt das nicht.

 

[AlArenal]

Wenn eine Klasse mehrere Interfaces implementiert, die wenigstens eine Methode mit gleicher Sig haben, muss ich mal dringend ein Refactoring durchführen, weil ich beim Design nicht aufgepasst habe.

Ich denke darauf können wir uns einigen.

 

[Beni]

Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...

Da hätte ich jetzt aber genau erwartet, dass Java dann diese sozusagen automatisch merged, da sie ja im Gegenteil zu einer Klasse, nicht schon implementiert sein können, und ich daher nicht bestimmen muss, welche Implementierung gewählt werden soll.

Missverständnis? Genau das tut Java.

Nur: zwar geht es Codemässig, und du kannst immernoch kompilieren, aber ob du eine Logik in die Methode (es ist nach dem Merge ja nur noch eine) bringst, steht auf einem anderen Blatt.

 

[kudi82]

Wenn eine Klasse mehrere Interfaces implementiert, die wenigstens eine Methode mit gleicher Sig haben, muss ich mal dringend ein Refactoring durchführen, weil ich beim Design nicht aufgepasst habe.

Ich denke darauf können wir uns einigen.

Also da das nur ein Problem der Benennung ist und es nun halt zweideutige Wörter gibt in unserer Sprache, hat es wohl nicht viel mit Design zu tun. Zudem sollte Design ja auch ein iterativer Prozess sein können.

 

[stev.glasow]

*abgeharkt*

 

[kudi82]

Ich glaube auch, das ganze ist ausdiskutiert.

 

[stev.glasow]

Hats denn geholfen?

 

[Beni]

Also ich fands lustig 8), hast du noch mehr Fragen kudi82? :bae:

 

[kudi82]

Hmm... schwierige Frage? Vom technischen her eigentlich nicht, da ich ja jetzt weiss, dass ich eigentlich so weiter machen muss wie bis jetzt. Das allererste Beispiel von mir war so natürlich schon nicht logisch, ist gut dass ich das nochmals überdenken musste.
Andere Ansichten sind immer interessant und bringen nicht nur mir Erfahrung. Ich würde aber sagen, auch andere haben davon profitiert, was ich so gelesen habe. Einige sind sich ihrer Kenntnisse glaube ich zu sicher, da ja die Probleme bei Kreisen und Punkten entstehen.

 

[kudi82]

Also ich fands lustig 8), hast du noch mehr Fragen kudi82? :bae:

Nö, jetzt ist eigentlich alles raus. Ich fands auch noch witzig.

(Lustig sind die Leute, die den Thread eigentlich völlig unnötig finden, aber trotzdem auf jeder Seite wieder irgendwo einen kleinen Kommentar abgegeben haben )

 

[AlArenal]

Du solltest deine Erfahrung nicht aus Diskussionen beziehen, sondern aus Praxis