Let's talk about kotlin's covariance and contravariance from Java

java Basic Tutorial column introduces covariance and contravariance of kotlin today.

Preface

In order to better understand covariance and contravariance in kotlin and Java, let’s first look at some basic knowledge.

Normal assignment

In Java, the common assignment statements are as follows:

A a = b;复制代码

The conditions that the assignment statement must meet are: the left side is either the parent class of the right side, or it is the same as the right side Same type. That is, the type of A must be "larger" than the type of B, such as Object o = new String("s");. For convenience, hereafter it is called A > B.

In addition to the most common assignment statements mentioned above, there are two other assignment statements:

Assignment of function parameters

public void fun(A a) {}// 调用处赋值B b = new B();
fun(b);复制代码

When calling the fun(b) method, Assign the passed actual parameter B b to the formal parameter A a, that is, in the form A a = b. Similarly, the formal parameter type must be greater than the actual parameter, that is, A > B.

Assignment of function return value

public A fun() {
    B b = new B();    return b;
} 
复制代码

The function return value type receives the value of the actual return type. The actual return type B b is equivalent to assigning a value to the function return value type A a, that is, B b assignment Given A a, that is, A a = b, then the type relationship of A > B must be satisfied.

So, no matter what kind of assignment, it must satisfy the left type > right type, that is, A > B.

Covariance and contravariance in Java

With the previous basic knowledge, covariance and contravariance can be easily explained.

If class A > class B, trans(A) and trans(B) obtained after changing trans still satisfy trans(A) > trans(B), then it is called agreement Change.

Contravariation is just the opposite. If class A > class B, the trans(A) and trans(B) obtained after a change trans satisfy trans(B) > trans(A), which is called Inverter.

For example, everyone knows that Java arrays are covariant. If A > B, then A[] > B[], so B[] can be assigned to A[]. For example:

Integer[] nums = new Integer[]{};
Object[] o = nums; // 可以赋值，因为数组的协变特性所以由 Object > Integer 得到 Object[] > Integer[]复制代码

But Java's generics do not satisfy covariance, as follows:

List<Integer> l = new ArrayList<>();
List<Object> o = l;// 这里会报错，不能编译复制代码

The above code reports an error because, although Object > Integer, the generics do not satisfy covariance. , so List<Object> > List<Integer> is not satisfied. Since the condition that the left side is greater than the right side is not satisfied, we know from the preface that naturally List< Integer> is assigned to List<Object>. It is generally said that Java generics do not support type variation.

How to implement covariance and contravariance with generics in Java

We know from the previous point that generics in Java do not support type changes, but this will produce a very strange Doubts are also mentioned in many articles about generics:

If B is a subclass of A, then List should be a subclass of List! This is a very natural idea!

But sorry, Java does not support it for various reasons. However, Java does not completely obliterate the variable characteristics of generics. Java provides and to make generics have covariance and contravariance characteristics.

and

are called upper bound wildcards, are called lower bound wildcards. Use upper bound wildcards to make generics covariant, and use lower bound wildcards to make generics contravariant.

For example, in the previous example

List<Integer> l = new ArrayList<>();
List<Object> o = l;// 这里会报错，不能编译复制代码

If you use the upper bound wildcard,

List<Integer> l = new ArrayList<>();
List<? extends Object> o = l;// 可以通过编译复制代码

In this way, the type of List will be larger than the type of List<Integer> , thus achieving covariance. This is what is called "a subclass of a generic is a subclass of a generic."

Similarly, the lower bound wildcard character can achieve inversion, such as:

public List<? super Integer> fun(){
    List<Object> l = new ArrayList<>();    return l;
}复制代码

How can the above code achieve inversion? First of all, Object > Integer; in addition, we know from the preface that the function return value type must be greater than the actual return value type, here it is List<? super Integer> > List<Object>, just the opposite of Object > Integer. In other words, after the generic change, the type relationship between Object and Integer is reversed. This is contravariance, and what implements contravariance is the lower bound wildcard .

As can be seen from the above, the upper bound in is T, which means that the types generally referred to by are all subclasses of T or T itself, so T is greater than . The lower bound in is T, that is to say, the types generally referred to by are the parent class of T or T itself, so is greater than T.

虽然 Java 使用通配符解决了泛型的协变与逆变的问题，但是由于很多讲到泛型的文章都晦涩难懂，曾经让我一度感慨这 tm 到底是什么玩意？直到我在 stackoverflow 上发现了通俗易懂的解释(是的，前文大部分内容都来自于 stackoverflow 中大神的解释)，才终于了然。其实只要抓住赋值语句左边类型必须大于右边类型这个关键点一切就都很好懂了。

PECS

PECS 准则即 Producer Extends Consumer Super，生产者使用上界通配符，消费者使用下界通配符。直接看这句话可能会让人很疑惑，所以我们追本溯源来看看为什么会有这句话。

首先，我们写一个简单的泛型类：

public class Container<T> {    private T item;    public void set(T t) { 
        item = t;
    }    public T get() {        return item;
    }
}复制代码

然后写出如下代码：

Container<Object> c = new Container<String>(); // (1)编译报错Container<? extends Object> c = new Container<String>(); // (2)编译通过c.set("sss"); // (3)编译报错Object o = c.get();// (4)编译通过复制代码

代码 (1)，Container<Object> c = new Container<String>(); 编译报错，因为泛型是不型变的，所以 Container 并不是 Container