Kovarianz und Kontravarianz

Kovarianz und Kontravarianz leicht erklärt: Producer vs. Consumer

Wer sich tiefer mit statisch typisierten Sprachen (wie Java, C#, TypeScript oder Scala) und Generics beschäftigt, stößt unweigerlich auf zwei Begriffe: Kovarianz und Kontravarianz (engl. Covariance und Contravariance).

Dahinter verbirgt sich eine sehr einfache und klare Regel, wie Typen sich zueinander verhalten, wenn sie Daten produzieren oder konsumieren.

Schauen wir uns das Ganze an einem klassischen Beispiel an: Hunde und Tiere.

Die Basis: Subtyping (Vererbung)

Beginnen wir mit einer simplen Tatsache der Objektorientierung: Ein Hund ist ein Tier. Er erbt von Tier. In der Typenlehre schreibt man das so:

Dog <: Animal

(Lesehilfe: Dog ist ein Subtyp von Animal)

Überall dort, wo im Code ein Animal verlangt wird, können wir problemlos einen Dog übergeben. Aber was passiert, wenn wir Generics oder Container wie Listen, Producer oder Consumer ins Spiel bringen?

Kovarianz: Der Producer (Lesen)

Ein Producer ist ein Datentyp, der Objekte ausgibt oder liefert (z. B. eine Liste, aus der wir nur lesen, oder eine Factory-Klasse).

Die Regel: Bei Producern bleibt die Vererbungsrichtung gleich. Sie verhalten sich kovariant (gleichsinnig).

         Dog  <:          Animal
Producer[Dog] <: Producer[Animal]

Warum ist das so?
Stell dir vor, du hast eine Funktion, die einen Producer[Animal] verlangt. Die Funktion erwartet also irgendetwas, das ihr Tiere liefert. Wenn du ihr nun stattdessen einen Producer[Dog] (z.B. eine Hundezucht) übergibst, ist das völlig in Ordnung! Alles, was der Producer[Dog] liefert, sind Hunde – und da jeder Hund auch ein Tier ist, wird die Erwartung der Funktion perfekt erfüllt.

Kontravarianz: Der Consumer (Schreiben)

Ein Consumer ist ein Datentyp, der Objekte entgegennimmt oder verarbeitet (z. B. ein Event-Listener oder ein Datenbankschreiber).

Die Regel: Bei Consumern dreht sich die Vererbungsrichtung um. Sie verhalten sich kontravariant (gegensinnig).

         Dog  <:          Animal
Consumer[Dog] >: Consumer[Animal]

(Lesehilfe: Ein Consumer[Dog] ist ein Supertyp, also: allgemeiner von/als Consumer[Animal]. Überall dort, wo ein Consumer[Dog] verlangt wird, kann also ein Consumer[Animal] einspringen.)

Consumer[Dog] ist der schwächere, also allgemeinere Vertrag.

Consumer[Animal] ist der stärkere, speziellere Vertrag. Er muss mit allen verschiedenen Animal Subtypen klarkomen, deshalb sind die Anforderungen an diesen größer. Also ist seine Ausprägung anspruchsvoller, und in diesem Sinne ist diese Klasse dann spezieller.

Warum ist das so?
Der Name kontravariant verrät es bereits: Die Vererbungsbeziehung verläuft hier exakt in die entgegengesetzte Richtung. Stell dir vor, eine API verlangt einen Consumer[Dog] – also jemanden, der einen Hund entgegennimmt und sich mit ihm beschäftigt (z. B. ihn füttert oder pflegt). Wenn du nun einen Consumer[Animal] (z. B. eine allgemeine Tierpflege-Station) übergibst, ist das völlig sicher und korrekt. Eine Tierpflege-Station weiß, wie man jedes beliebige Tier behandelt. Wenn wir ihr also einen Hund übergeben, kommt sie damit spielend zurecht.

Wer jemanden braucht, der sich um Hunde kümmert, kann problemlos eine allgemeine "Tier"-Pflegestation nutzen, denn diese kann ganz selbstverständlich auch mit Hunden umgehen.

Zusammenfassung

Kovarianz:
Ich darf einen spezielleren Lieferanten benutzen.

Kontravarianz:
Ich darf einen allgemeineren Empfänger benutzen.

Ein Blick über den Tellerrand: Was ist, wenn wir auf OOP verzichten?

Spielen Kovarianz und Kontravarianz überhaupt eine Rolle, wenn man auf Objektorientierte Programmierung (OOP) ganz verzichtet?

Ja, absolut. Kovarianz und Kontravarianz spielen auch dann eine zentrale Rolle.

Diese Konzepte (zusammenfassend als "Varianz" bezeichnet) sind keine Erfindungen der OOP. Sie stammen ursprünglich aus der Typtheorie und der Kategorientheorie. Sie sind in jedem statischen Typsystem relevant, das Untertypen (Subtyping) oder parametrische Polymorphie (Generics) unterstützt – völlig unabhängig vom gewählten Programmierparadigma.

Hier sind die wichtigsten Bereiche außerhalb der OOP, in denen Varianz unverzichtbar ist:

1. Funktionstypen (Higher-Order Functions)

Das fundamentalste Beispiel für Varianz findet sich in der funktionalen Programmierung beim Übergeben von Funktionen (Callbacks). Damit ein Typsystem sicherstellen kann, dass eine übergebene Funktion zur Laufzeit typsicher arbeitet, wendet es eine feste Regel für das Subtyping von Funktionen an:

• Funktionen sind in ihren Parametertypen (Eingabe) kontravariant.
• Funktionen sind in ihren Rückgabetypen (Ausgabe) kovariant.

Ein anschauliches Beispiel: Wenn eine Funktion als Parameter einen Callback vom Typ (Tier) -> Hund erwartet (nimmt ein Tier, gibt einen Hund zurück), ist es sicher, stattdessen eine Funktion vom Typ (Lebewesen) -> Pudel zu übergeben. Die Eingabe darf allgemeiner sein (Kontravarianz: Lebewesen ist der Supertyp von Tier), während die Ausgabe spezifischer sein darf (Kovarianz: Pudel ist ein Subtyp von Hund).

2. Funktionale Programmierung (Typklassen)

In stark typisierten, rein funktionalen Sprachen wie Haskell existiert keine Vererbung im OOP-Sinne. Stattdessen wird Varianz explizit durch Typklassen gemacht, die direkt auf kategorientheoretischen Prinzipien basieren:

• Kovarianz (Functor): Ein Datentyp wie eine Liste ist ein Funktor. Man kann eine Transformation (z. B. via map) auf die Struktur anwenden, wodurch aus einem List[A] ein List[B] wird, ohne die innere Struktur aufzubrechen.
• Kontravarianz (Contravariant): Dies tritt bei Typen auf, die Werte "konsumieren" statt sie zu produzieren, wie beispielsweise Prädikate (Filterbedingungen) oder Sortier-Comparatoren.
• Profunktoren (Profunctor): Strukturen, die sowohl kontravariante als auch kovariante Parameter besitzen, wie eben Funktionstypen, die etwas annehmen und etwas anderes zurückgeben.

3. Strukturelles Subtyping

In Sprachen mit strukturellen Typsystemen (z. B. TypeScript oder OCaml), wenn diese rein datengetrieben ohne Klassen genutzt werden, wird die Typ-Kompatibilität durch die Form der Daten (Records, Interfaces) bestimmt. Sobald du verschachtelte Typ-Aliase oder Unions zuweist, rechnet der Compiler im Hintergrund permanent mit den Varianz-Regeln, um zu entscheiden, ob Datensatz A typsicher anstelle von Datensatz B verwendet werden darf.

Das Fazit:
OOP macht Varianz für viele Entwickler lediglich sichtbarer, da sie eng mit expliziten Vererbungshierarchien (z. B. class Hund extends Tier) und Sprachfeatures wie <? extends T> in Java oder in/out in Kotlin und C# verwoben wird. Das zugrunde liegende Prinzip – die Gewährleistung der Typsicherheit beim Zusammensetzen komplexer Daten- und Funktionstypen – ist jedoch ein universelles, mathematisches Konzept der gesamten Informatik.