我们还应该考虑编译器如何威胁泛型类：每当我们填充泛型参数时，“实例化”一个不同的类型。

因此，我们有ListOfAnimal、ListOfDog、ListOfCat等，它们是不同的类，当我们指定泛型参数时，最终由编译器“创建”。这是一个扁平的层次结构（实际上关于List根本不是一个层次结构）。

在泛型类的情况下，协方差没有意义的另一个论点是，基本上所有类都是相同的-都是List实例。通过填充泛型参数来专门化List并不会扩展类，它只会使其适用于特定的泛型参数。

另一个解决方案是建立一个新的列表

List<Dog> dogs = new ArrayList<Dog>(); 
List<Animal> animals = new ArrayList<Animal>(dogs);
animals.add(new Cat());

您要查找的是所谓的协变类型参数。这意味着，如果在方法中可以用一种类型的对象替换另一种类型（例如，Animal可以替换为Dog），那么同样的情况也适用于使用这些对象的表达式（因此List＜Animal＞可以替换为List＜Dog＞）。问题是，一般来说，协方差对于可变列表来说是不安全的。假设您有一个List<Dog>，并且它被用作List<Animal>。当你试图将一只猫添加到这个列表<动物>中时会发生什么？自动允许类型参数为协变会破坏类型系统。

添加语法以允许将类型参数指定为协变将是有用的，这避免了？在方法声明中扩展了Foo，但这确实增加了额外的复杂性。

我们还应该考虑编译器如何威胁泛型类：每当我们填充泛型参数时，“实例化”一个不同的类型。

因此，我们有ListOfAnimal、ListOfDog、ListOfCat等，它们是不同的类，当我们指定泛型参数时，最终由编译器“创建”。这是一个扁平的层次结构（实际上关于List根本不是一个层次结构）。

在泛型类的情况下，协方差没有意义的另一个论点是，基本上所有类都是相同的-都是List实例。通过填充泛型参数来专门化List并不会扩展类，它只会使其适用于特定的泛型参数。

让我们以JavaSE教程为例

public abstract class Shape {
    public abstract void draw(Canvas c);
}

public class Circle extends Shape {
    private int x, y, radius;
    public void draw(Canvas c) {
        ...
    }
}

public class Rectangle extends Shape {
    private int x, y, width, height;
    public void draw(Canvas c) {
        ...
    }
}

因此，为什么狗（圆圈）的列表不应被视为动物（形状）的列表，是因为这种情况：

// drawAll method call
drawAll(circleList);


public void drawAll(List<Shape> shapes) {
   shapes.add(new Rectangle());    
}

因此，Java“架构师”有两个选项可以解决这个问题：

不要认为子类型是隐式的，它是父类型，并给出编译错误，就像现在发生的那样将子类型视为它的父类型，并在编译“add”方法时进行限制（因此在drawAll方法中，如果要传递圆的列表（形状的子类型），编译器应该检测到这一点，并用编译错误限制您这样做）。

出于明显的原因，他们选择了第一条路。

这里给出的答案并不能完全说服我，所以我再举一个例子。

public void passOn(Consumer<Animal> consumer, Supplier<Animal> supplier) {
    consumer.accept(supplier.get());
}

听起来不错，不是吗？但你只能通过动物消费者和供应商。如果你有哺乳动物的消费者，但鸭子的供应商，尽管它们都是动物，但它们不应该适合。为了禁止这种行为，增加了额外的限制。

我们必须定义我们使用的类型之间的关系，而不是上述内容。

例如。，

public <A extends Animal> void passOn(Consumer<A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

确保我们只能使用为消费者提供正确类型对象的供应商。

OTOH，我们也可以

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<A> supplier) {
    consumer.accept(supplier.get());
}

我们的方向相反：我们定义供应商的类型，并限制其可以投放给消费者。

我们甚至可以做到

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

其中，有了“生活”->“动物”->“哺乳动物”->“狗”、“猫”等直观关系，我们甚至可以将“哺乳动物”放入“生活”消费者，但不能将“字符串”放入“生命”消费者。