Le exacte Les règles de validité de la variance sont un peu vagues et non spécifiques. Je vais énumérer les règles de ce qui rend un type valide-covariant et joignez des questions et des annotations personnelles à chacune de ces règles.
Un type est 1) un type de pointeur ou un type non générique.
Les pointeurs et les types non génériques ne sont pas une variante dans C #, à l'exception des tableaux et des délégués non génériques. Les classes génériques, les structures et les énumérums sont invariants. Suis-je raison ici?
2) Un type de tableau T [] où T est valide covarienne.
Cela signifie que si le type d'élément 3) Un type de paramètre de type générique, s'il n'a pas été déclaré comme contravare.
Nous disons normalement qu'un type générique est une variante sur un type de paramètre, mais pour un type de paramètre à variante est propre. Est-ce une autre forme courte pour dire cela? Par exemple, le type générique 4) Une classe construite, une structure, un énumération, une interface ou un délégué de type x pourrait être valide de manière coovarienne. Pour déterminer si c'est le cas, nous examinons chaque argument de type différemment, selon que le paramètre de type correspondant a été déclaré comme covariant (OUT), Contraveurt (IN) ou invariant (ni invariant (ni). (Bien sûr, les paramètres de type générique des classes et des structures ne seront jamais déclarés «out» ou «dans»; ils seront toujours invariants.) Si le paramètre de type ITH a été déclaré comme covariant, alors TI doit être valide de manière coovarienne. Si cela a été déclaré comme contrevenue, TI doit être valable contrefaviertly. Si cela a été déclaré invariant, TI doit être valide invariant.
Parlez-nous d'une variance de type générique sur tous ses paramètres de type IN / OUT / invariant? Par définition, un type générique peut être covariant / Contraveurt / invariant sur un paramètre de type à la fois. Pour être covariant ou invariant, dans ce cas, sur tous les paramètres de type de type à la fois ne contiennent aucune signification. Qu'est-ce que cela pourrait signifier?
aller de l'avant. Pour déterminer si le type générique est valide de manière covarienne, nous examinons ses arguments de type J'ai besoin que cette règle soit expliquée plus en profondeur.
EDIT: Merci Eric. Grandement apprécié!
Je comprends parfaitement ce que signifie une moyenne covariante / invariante valide / invariante. Un type est valide coviantliant, si ce n'est certainement pas contrevenue, ce qui signifie que cela peut être invariant. Parfaitement bien!
Pour la 4ème règle, vous suivez la procédure de détermination de la manière de déterminer si un type générique construit est valide de manière coovarienne, telle que définie dans la règle. Mais comment déterminez-vous si un argument de type déclaré comme Covariant (OUT) est valide de manière covarienne?
Par exemple, dans la aussi, la deuxième règle:
2) Un type de tableau T [] où T est valide covarienne.
Qu'est-ce que cuz la projection
t d'un tableau t [] est covariant (type d'élément de référence ou tableau), puis le tableau est covariant, et si Le type d'élément est invariant (type de valeur), puis le type de tableau est invariant. Les tableaux ne peuvent pas être contravariat en C #. Suis-je raison ici?
t d (valide de manière covarienne), par conséquent, nous pouvons dire que le paramètre type d est valide de manière covarienne? Ai-je raison?
objet est déclaré comme un paramètre Covariant Type Paramètre (Out U) dans la déclaration d'interface générique signifie que l'objet d'argument de type est covariant? Je pense que ça devrait. Cuz c'est la définition même d'être covariant.
t étant valide covariant moyenne? Voulez-vous dire que le type d'élément étant un type t → t [] est seulement une variante si t est un type de référence.
3 Réponses :
Non, vos annotations sont gâchées.
Cet article est vraiment difficile à comprendre, en partie parce que "Valide Covariandly" n'a rien du tout à faire avec la covariance. Eric fait remarquer cela, mais cela signifie pour chaque phrase que vous devez "impressionner" le sens naturel, puis penser en termes de ces définitions étranges pour "Valable Covariandly", "Valid Confirmythly" et "Valable invariant".
Je vous recommande vivement de lire à la place du principe de substitution de Liskov, puis de penser à la substituabilité. La covariance, la contrevenance et l'invariance ont des définitions très simples lorsqu'elles ont examiné le point de vue de la LSP.
Ensuite, vous remarquerez peut-être que les règles C # au moment de la compilation ne correspondent pas exactement au LSP (malheureusement - et il s'agit principalement d'une erreur faite en Java et de copie en C # pour aider les programmeurs de cour Java). D'autre part, au moment de l'exécution, les règles de la LSP doivent être suivies, donc si vous commencez avec ceux-ci, vous écrirez du code qui compile et exécute correctement, ce qui, je pense, est une entreprise plus utile que Apprendre les règles de langue C # (sauf si vous écrivez un compilateur C #).
Vous avez raison que la dernière règle est la plus difficile à comprendre, mais je vous assure que ce n'est pas ambigu.
Un exemple ou deux aidera. Considérons cette déclaration de type: P>
interface IEnumerable<out W> { ... }
interface I<in T, out U, V>
{
IEnumerable<T> M();
}
Merci Eric. Pouvez-vous répondre aux deux nouvelles petites questions ajoutées à la fin de mon poste d'origine?
Ce n'est vraiment pas comme si Eric Lippert soit vague ou ambiguë. Pour que je puisse attendre qu'il pèse avant de tester la profondeur de cette petite flaque d'eau.
Cet article est différent Gjeltema. Dans mon précédent publipostage sur la variance, ma compréhension de la variance et ses terminologies associées à court terme ont été clarifiées.