Detailed explanation of contravariance and covariance in C#

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 List() and plist = new List() produce compilation mistake. Although Person is the parent class of Student/Teacher, the List type is not the parent class of the List 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 List plist = new List() allows assignment, then although the type of plist is List collection. plist.Add(new Person()), the actual addition operation calls List.Add(). The Person type cannot be safely converted to Student, so such a collection definition does not make sense, so the above assumption does not hold.

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 Work. 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 Work to variables of type Work.

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 . 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!