Hallo Christian,
Der generische Typ-Parameter in IProgress<T> ist - wie man am "in"-Schlüsselwort sehen kann - als
kontravariant definiert:
public interface IProgress<in T> {
void Report(T value);
}
Wenn man "in" für ein Typparameter angibt (das ist bei
IList<T> genauso), funktioniert das wie eine generische Typ-Einschränkung. D.h. man kann mit
IProgress entweder genau den Typ verwenden, den man in der Deklaration angegebenen hat (MyContact), oder aber einen weniger abgeleiteten Typ, z.B. einen hypothetischen
ContactBase. Aber keinen Typ der von MyContact selbst abgeleitet ist, z.B.
MyDerivedContact. Letzeres würde nur in einem kovarianten Szenario, z.B. mit
IEnumerable<T> gehen.
Der Unterschied zwischen kovarianten und kontravarianten Typparameter kann leicht anhand von Beispielen erklärt werden. Während
IProgress<T> T-Werte empfangen kann:
public interface IProgress<in T> {
void Report(T value);
}
ist dies bei IEnumerable<T> nicht der Fall, IEnumerable<T> kann T nur
zurückgeben:
public interface IEnumerable<out T> : IEnumerable {
IEnumerator<T> GetEnumerator();
}
Auch IReadOnlyList<T> ist kovariant, das einzige Problem ist also IProgress<T> und seine kontravariante Einschränkung. Aber wäre die nicht da, wie könnte man noch Typsicherheit gewährleisten und woher wüsste der empfangende Code welche Methoden
auf T vorhanden und welche nicht vorhanden sind.
Aber vielleicht habe ich auch nicht genau verstanden, worum es dir geht?
s.a.
Varianz in generischen Schnittstellen.
Gruß
Marcel
Spezialisierung in generischen Schnittstellen
