Home  >  Article  >  Backend Development  >  Detailed explanation of contravariance and covariance in C#

Detailed explanation of contravariance and covariance in C#

黄舟
黄舟Original
2017-09-02 14:32:041235browse

This article mainly introduces the relevant information of C# inversion and covariance in detail. It has certain reference value. Interested friends can refer to it.

This article uses more Delegates and Lambda expressions. If you are not familiar with these, please check out my articles "Delegates and Anonymous Delegates" and "Anonymous Delegates and Lambda Expressions" to help you build a complete knowledge system.

In the process of C# from its birth to its development and growth, new knowledge points are constantly introduced. Contravariance and covariance are not original to C# and will be introduced later. Contravariance and covariance also exist in Java. I will also write an article on Java contravariance and covariance in the future. Friends who are interested can pay attention to it.

Contravariance and covariance sound abstract and profound, but they are actually very simple. Look at the following code:


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>();
}
}

In the above code, the two sentences plist = new List1f479e44f2c9bd2301ecbd2b69e4d7bf() and plist = new Lista8bdf01faaf42061e3f9f34321fc482d() produce compilation mistake. Although Person is the parent class of Student/Teacher, the List8abf60ac54173a2785e603c7a1f95b4e type is not the parent class of the List9b1b1f91ff4e07aaba823b16332dd083 type, so the above assignment statement reports a type conversion failure error.

Assignment operations like the above were not allowed before C# 4.0. As for why they are not allowed, type safety is the primary factor. Look at the following sample code:


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

The following example assumes that List8abf60ac54173a2785e603c7a1f95b4e plist = new List1f479e44f2c9bd2301ecbd2b69e4d7bf() allows assignment, then although the type of plist is List

But the situation has changed after C# 4.0. It is not that "impossible things have happened", but that the flexibility of the application has made new adjustment. Similarly, the above program is still not allowed in C# 4.0, but an exception occurs. Starting from C# 4.0, special situations are allowed to occur in generic delegates and generic interfaces (in essence, no special changes have occurred, which will be explained later). The following example:


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; //此处编译错误
  }
}

According to the previous theoretical support, the error of student_worker = worker; is easy to understand. But the purpose of our program here is to let worker function as Work1f479e44f2c9bd2301ecbd2b69e4d7bf. In the future, calling student_worker(s) will actually call waker(s). In order to meet our needs, the program needs to do two aspects of processing:

1. Because when calling student_worker(s), what is actually executed is waker(s), so the type of the s variable needs to be successfully converted to The parameter type required by worker.

2. You need to tell the compiler that it is allowed to assign objects of type Work8abf60ac54173a2785e603c7a1f95b4e to variables of type Work1f479e44f2c9bd2301ecbd2b69e4d7bf.

Condition 1 When calling student_worker(), the compiler will prompt that the parameter must be a Student type object, which can be successfully converted to a Person type object.

Condition 2 requires adjustments to the Woke delegate definition as follows:


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

The delegate name is changed to WorkIn to distinguish the delegates before and after the modification. The key point is 6f9802517dbf33d9eaf907870b00da1a. By adding the in keyword, mark the type parameter T of the generic delegate and use it only as a parameter of the delegate method. At this point the above program can be successfully compiled and executed.


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#" });

  }
 }

The situation that requires the type parameter to be a subtype and allows the assigned type parameter to be a parent type value is called contravariance. Contravariance requires in to mark the type parameters of generics in C#. Although contravariance is called contravariance, it only formally looks like the parent class object is assigned to the subclass variable. In essence, it is the type conversion of the parameters when the method is called. Student s = new Person(), this is impossible, this is not contravariant, it is an error.

If you can convert the above code into the following form, then you can forget about inversion. The essence is more important than the phenomenon.

The above is the detailed content of Detailed explanation of contravariance and covariance in C#. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn