Diskussion:Kovarianz und Kontravarianz

Unverstaendlich

Zitat: Kovarianz bedeutet, dass die Typhierarchie der Parameter/Ergebnistypen mit der Vererbungshierarchie der zu betrachtenden Klassen die selbe Richtung hat.

Noch Fragen? -- sparti 20:01, 10 November 2005 (CET)

Moin Moin.

Kann man das eigentlich auch so formulieren, dass der Begriff der informatischen und der physikalischen Kovarianz durch einen gemeinsamen Oberbegriff erklaert und hier nur spezialisiert werden. Das wuerde vielleicht die Willkuer aus der Formulierung nehmen. _Tschuess, __Michael.

ich bin hier gelandet, weil ich wissen wollte, was es heißt, wenn eine Matrix "invariant unter Zeilenoperationen" ist, habe dazu aber nichts gefunden. Ist es sinnvoll, den mathematischen Aspekt hier mit einzufügen, oder sollte man besser einen Artikel "Invarianz(Mathematik)" eröffnen?

-- Undergaveragent 13:09, 21. Mär 2006 (CET)

____________________ mailto:wikipaedie@soliman.de

Unverstaendlich 2.0

Bin gerade auf die Seite hier gestossen, bin selbst Informatiker und was soll ich sagen: Bevor ich das hier gelesen habe, wusste ich noch was Ko- und Kontravarianz sind. :> Die Beispiele sind boesartig schlecht erklaert und mEn sollte man aus Verstaendnisgruenden die erbenden Strukturen nach unten schreiben - nicht umgekehrt. Darueber hinaus wird vom ersten Beispiel an davon ausgegangen dass Kovarianz nur Ergebnistypen betrifft, Kontravarianz nur Paramatertypen.. ist so auch nicht wirklich richtig. Das sollte nochmal richtig gegliedert werden, und die Grafikbeispiele eventuell deutlicher gemacht. [Es wird nichtmal erklaert inwiefern Klasse A und B in Verbindung stehen]. --Schwarzer8Kater 09:26, 8. Okt. 2007 (CEST)

Sei mutig und verbessere den Artikel. :-) --jpp ?! 17:29, 8. Okt. 2007 (CEST)

Unverstaendlich n+1

Zum Eingangssatz: es sollte jeweils nur ein Begriff in einem Satz erläutert werden. Zudem: "Aspekt", "Vererbungsrichtung", "Oberklasse", "Unterklasse" - wie bitte? Wieviele Richtungen gibt es denn in der Vererbung? Was ist eine Oberklasse in der OOP? Gemeint ist vermutlich die Basisklasse. Und die Unterklasse - soll das sein? Vermutlich die abgeleitete Klasse.

Zum Schluss: was ist das denn jetzt die Kovarianz bzw. die Kontravarianz? 79.193.79.208 10:50, 29. Jul. 2009 (CEST)

Typsicherheit

Warum hat man in Vererbungsbeziehungen keine Typsicherheit mehr, wenn sowohl Rückgabetyp als auch Methodenargument kovariant sind?

Jetzt gibt es ein Beispiel mit Erklärung. Verständlich? Noch Fragen? Noch andere Fragen?--Algos 13:08, 25. Aug. 2007 (CEST)

Das Beispiel ist schlecht bis falsch gewählt. Es steht dort der Vermerk: Java Code, bei Java geht aber alles gut, denn für den Aufruf führeFahrzeug mit einem Fahrzeug als Parameter an einem Objekt vom Typ Lokführer wird natürlich die Implementation von Fahrzeugführer aufgerufen und überhaupt keine Abfrage von fahrzeug.waggons durchgeführt.

Dass Beispiel ist nicht nur äußerst schlecht gewählt, es ist auch falsch. Es funktioniert nämlich aufgrund der Überladung der Methode, und nicht weil plötzlich Kovarianz bzgl. der Parametern erlaubt wäre. Das ist es nämlich explizit nicht! Deswegen von Typunsicherheit zu sprechen halte ich für ziemlichen Blödsinn. Ein Autor derartigen Codes hat an dieser Stelle explizit gewollt, dass es eine zweite Methode mit dem selben Methodennamen parallel zu der anderen gibt und er hat dafür auch explizit eine zweite Methode implementiert. Er muss sie sogar explizit implementieren. Typunsicherheit würde nur dann auftreten, wenn Java hier die Methode nicht überladen, sondern überschreiben würde. Aber genau dass passiert nicht. Ich würde den kompletten Abschnitt löschen, oder max. und ganz ganz vorsichtig von "Schein-Typunsicherheit" sprechen. --217.83.3.72 13:55, 20. Sep. 2010 (CEST)

Kontravarianz falsch

Die Kontravarianz im Beispiel ist nicht richtig! Ich glaube so soll es sein:
OT (f:OT x OT -> OT)
T (f: T x T -> T)
NT (f: ? x  ? ->  ?)
(T erbt von OT und NT von T)
NT : Invarianz f (f: T x T -> T)
NT : Kovarianz f (f:NT x NT -> NT)
NT : Kontravarianz f (f: OT x OT -> OT)

Totaler Schrott

Spätestens mit der Einführung von Generics in Mainstream-OO-Sprachen muss man folgendes feststellen: Das ständige Reden von Vererbunghierarchien, Klassen usw. ist viel zu eingeschränkt. Klar, eine Ableitung im OO-Sinne impliziert eine Subtyprelation. Aber nicht umgekehrt. Ist z.B. List<String> von List<Object> abgeleitet? Natürlich nicht. Aber eine Untertyprelation besteht ggf., je nach Sprache und sonstigem Kontext (und die Richtung ist auch nicht von vorn herein klar). Der Artikel in der englischen Wikipedia geht da einen etwas besseren Weg. Wenn ich Lust und Zeit hab', stelle ich den hier mal um. Vielleicht hat ja jemand Lust zu kooperieren. --Daniel5Ko 00:08, 1. Jul. 2010 (CEST)

4. Spalte von "Kovarianz, Kontravarianz und Invarianz im Überblick"

In der 2. und 3. Spalte der Tabelle "Kovarianz, Kontravarianz und Invarianz im Überblick" wird eine sinnvolle Anwendung der Kontravarianz (2. Spalte) und eine sinnvolle Anwendung der Kovarianz angegeben (3. Spalte). Und warum dies sinnvoll ist, wird auch im Artikel erklärt. Aber warum ist die Invarianz in der 4. Spalte (bei einem pass-by-reference-Parameter) sinnvoll? Nach meinem Verständnis sollte diese Spalte aus der Tabelle verschwinden. Oder es sollte erklärt werden warum Invarianz bei pass-by-reference sinnvoll ist (was sie meiner Meinung nach aber eben nicht ist). Eine dritte Möglichkeit wäre, eine neue Tabelle anzufangen, und in dieser mehrere mögliche, aber nicht unbedingt sinnvolle X-varianz-Möglichkeiten zu zeigen. Sind noch andere dieser Meinung? -- Wortverdreher 21:40, 5. Dez. 2011 (CET)

Die c#-Beispiele zu Kovarianz und Kontravarianz verfehlen leider völlig das Thema.

Kovarianz bei Rückgabetypen

Man zeigt die Covarianz eines Rückgabetyps NICHT mit einem Aufruf der Methode und den nach der Rückkehr aus der Methode stattfindenden Casts, sondern dadurch, dass man sich die Definitionen der Methode in der Basisklasse und in der abgeleiteten Klasse anschaut und die Rückgabe-Typen vergleicht!

Im englischen Wiki gibt es ein sinnvolles, der Definition des Begriffs Rechnung tragendes Beispiel:

Zitat aus dem englischen Wikipedia:

„

class AnimalShelter 
{
        Animal getAnimalForAdoption() {
          ...
        }
    
        void putAnimal(Animal animal) {
          ...
        }
    }

In a language which allows covariant return types, a derived class can override the getAnimalForAdoption method to return a more specific type:

class CatShelter extends AnimalShelter {
        Cat getAnimalForAdoption() {
    	    return new Cat();
        }
    }

“

Dass der Typ des Rückgabewerts der überladenden Methode getAnimalForAdoption (in der abgeleiteten Klasse) nicht einfach wieder, wie in der Basisklasse, Animal ist, sondern ein Subtyp davon SEIN DARF, DAS ist die Besonderheit, die man mit Kovarianz bezeichnet. Kovariant = Gleichlauf der Ableitungsrichtungen bei der Methoden-Klasse und der Rückgabe-Klasse.

Nicht jede Programmiersprache lässt das zu! Wieder aus dem englischen Wiki

„Among mainstream OO languages, Java and C++ support covariant return types, while C# does not“

Ich kenne mich mit c# zu wenig aus, weiß also nicht, ob Kovarianz bei Rückgabewerten nicht mittlerweile doch ein Sprachfeature in c# ist, aber das, was hier im Artikel als Beispiel angebracht wird, funktioniert so oder so ähnlich schon sehr lange in c#, das beißt sich also auf jeden Fall mit der Aussage im englischen Wiki.

Kontravarianz bei Argument-Typen

Wieder das gleiche. Man muss sich die Definitionen der Methoden anschauen und dort die Typen der Argumente vergleichen.

Weiter aus dem englischen Wiki:

„Kontravariant method argument type

class AnimalShelter {
        Animal getAnimalForAdoption() {
          ...
        }
    
        void putAnimal(Animal animal) {
          ...
        }
    }

    class CatShelter extends AnimalShelter {
        void putAnimal(Object animal) { // <--------- hier steht Objekt, obwohl in der Basisklasse Animal "gefordert" ist. - 
                                        // Der Begriff Kontravarianz bezeichnet die Möglichkeit zu dieser Gegenläufigkeit der Ableitungsrichtung von Methodenklasse und Parameterklasse
           ...
        }
    }

Not many object-oriented languages actually allow this. C++ and Java would interpret this as an unrelated method with an overloaded name.“

Damit ist auch klar, dass das Beispiel für Invarianz ebenfalls einen Vergleich von Typen (Return- und Parametertypen) zwischen Basisklasse und abgeleiteter Klasse braucht.

Bevor ich das im Artikel ändere, bitte ich um Review. Sehr gern kann das auch jemand anderes im Artikel ändern.

Vielen Dank und viele Grüße, --MrGoldbeere (Diskussion) 14:31, 15. Jul. 2016 (CEST)

C# bloß Zuweisungskompatibilität

Das C#-Beispiel zeigt keineswegs Ko- oder Kontravarianz, sondern bloß Zuweisungskompatibilität! Tatsächlich sind Ko- und Kontravarianz in C# nur für Delegaten, Array- und generische Typen verfügbar (leiderleider). Googelt man den Themenkomplex, tut die C#-Community so, als seien dies die einzig denkbaren Anwendungsmöglichkeiten dieses Konzepts. Sie ignoriert damit die wesentlich ältere Anwendung wie sie im allgemienen Teil des Artikels weitgehend richtig dargestellt wird. (nicht signierter Beitrag von HB Jepsen (Diskussion | Beiträge) 01:44, 23. Jul 2016 (CEST))

Das C#-Beispiel für Invarianz funktioniert hinten und vorne nicht.

Fehler CS0103 Der Name "GetNameFromGiraffe" ist im aktuellen Kontext nicht vorhanden.
Fehler CS0534 "Giraffe" implementiert den geerbten abstrakten Member "Animal.Name.get" nicht.
Fehler CS0116 Member, wie z. B. Felder oder Methoden, können nicht direkt in einem Namespace enthalten sein.
Fehler CS0246 Der Typ- oder Namespacename "Test" wurde nicht gefunden (fehlt eine using-Direktive oder ein Assemblyverweise?)
--80.153.250.36 16:19, 10. Aug. 2016 (CEST)