Explication détaillée de la contravariance et de la covariance en C#

Cet article présente principalement en détail les informations pertinentes sur l'inversion et la covariance C#, qui ont une certaine valeur de référence. Les amis intéressés peuvent s'y référer

Cet article utilise plus d'expressions de délégués et Lambda. avec ceux-ci, veuillez consulter mes articles « Délégués et délégués anonymes » et « Délégués anonymes et expressions Lambda » pour vous aider à construire un système de connaissances complet.

Dans le processus du C# depuis sa naissance jusqu'à son développement et sa croissance, de nouveaux points de connaissances sont constamment introduits. La contravariance et la covariance ne sont pas originales en C# et seront introduites plus tard. La contravariance et la covariance existent également en Java. J'écrirai également un article sur la contravariance et la covariance Java à l'avenir. Les amis intéressés peuvent y prêter attention.

La contravariance et la covariance semblent abstraites et profondes, mais elles sont en réalité très simples. Regardez le code suivant :

class Person
 {

 }
 class Student : Person
 {

 }
 class Teacher: Person
 {

 }
 
 class Program
 {
  static void Main(string[] args)
  {
   List<Person> plist = new List<Person>();
   plist = new List<Student>();
   plist = new List<Teacher>();
}
}

Dans le code ci-dessus, plist = new List(), plist = new List() Une compilation une erreur se produit. Bien que Person soit la classe parent de Student/Teacher, le type List n'est pas la classe parent du type List, donc l'instruction d'affectation ci-dessus signale une erreur d'échec de conversion de type.

Les opérations d'affectation comme celles ci-dessus n'étaient pas autorisées avant C# 4.0 Quant à savoir pourquoi elles ne sont pas autorisées, la sécurité des types est le principal facteur. Regardez l'exemple de code suivant :

List<Person> plist = new List<Student>();
plist.Add(new Person());
plist.Add(new Student());
plist.Add(new Teacher());

L'exemple suivant suppose que List plist = new List() autorise l'affectation, alors bien que le type de plist est la collection List, mais elle pointe en fait vers la collection List plist.Add(new Person()), l'opération d'addition réelle appelle List.Add(). Le type Personne ne peut pas être converti en toute sécurité en Étudiant, donc une telle définition de collection n'a pas de sens, donc l'hypothèse ci-dessus n'est pas valable.

Mais la situation a changé après C# 4.0. Ce n'est pas que "des choses impossibles se sont produites", mais que la flexibilité de l'application a fait de nouveaux ajustements. De même, le programme ci-dessus n'est toujours pas autorisé en C# 4.0, mais une exception se produit. À partir de C# 4.0, des situations spéciales sont autorisées à se produire dans les délégués génériques et les interfaces génériques (en substance, aucune modification particulière n'a eu lieu, ce qui sera expliqué plus tard). L'exemple suivant :

delegate void Work<T>(T item);

class Person
{
  public string Name { get; set; }
}
class Student : Person
{
  public string Like { get; set; }
}
class Teacher : Person
{
  public string Teach { get; set; }
}

class Program
{
  static void Main(string[] args)
  {
   Work<Person> worker = (p) => { Console.WriteLine(p.Name); }; ;
   Work<Student> student_worker = (s) => { Console.WriteLine(s.Like); };
   student_worker = worker; //此处编译错误
  }
}

D'après le support théorique précédent, l'erreur de student_worker = work est facile à comprendre. Mais le but de notre programme ici est de permettre au travailleur de fonctionner en tant que Work. À l'avenir, appeler student_worker(s) appellera en fait waker(s). Afin de répondre à nos besoins, le programme doit effectuer deux aspects du traitement :

1 Parce que lors de l'appel de student_worker(s), ce qui est réellement exécuté est waker(s), donc le type de la variable s. doit être converti avec succès en type de paramètre requis par le travailleur.

2. Vous devez indiquer au compilateur qu'il est autorisé à attribuer des objets de type Work à des variables de type Work.

Condition 1 Lors de l'appel de student_worker(), le compilateur demandera que le paramètre doit être un objet de type Student, qui peut être converti avec succès en un objet de type Person.

La condition 2 nécessite des ajustements à la définition du délégué Woke. Les ajustements sont les suivants :

delegate void WorkIn<in T>(T item);

Le but de changer le nom du délégué en WorkIn est. pour éviter les changements avant et après la délégation, le point clé est . En ajoutant le mot-clé in, marquez le paramètre de type T du délégué générique et utilisez-le uniquement comme paramètre de la méthode déléguée. À ce stade, le programme ci-dessus peut être compilé et exécuté avec succès.

delegate void WorkIn<in T>(T item);
class Program
 {
  static void Main(string[] args)
  {
   WorkIn woker = (p) => { Console.WriteLine(p.Name); };
   WorkIn student_worker = woker;
   student_worker(new Student() { Name="tom", Like="C#" });

  }
 }

La situation qui nécessite que les paramètres de type soient des sous-types et permet aux paramètres de type d'affectation d'être des valeurs de type parent est appelée contravariance. Contravariance en C# nécessite de marquer les paramètres de type des génériques. Bien que la contravariance soit appelée contravariance, il semble que formellement l'objet de classe parent soit affecté à la variable de sous-classe. Il s'agit essentiellement de la conversion de type des paramètres lorsque la méthode est appelée. Student s = new Person(), c'est impossible, ce n'est pas contravariant, c'est une erreur.

Si vous pouvez convertir le code ci-dessus sous la forme suivante, alors vous pouvez oublier l'inversion. L'essence est plus importante que le phénomène.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!