为什么使用通配符捕获辅助方法？

Question

参考：通配符捕获辅助方法

它说创建一个助手方法来捕获通配符。

public void foo(List<?> i) {
    fooHelper(i);
}        
private <T> void fooHelper(List<T> l) {
    l.set(0, l.get(0));
}

仅使用下面的函数不会产生任何编译错误，并且似乎以同样的方式工作。我不明白的是：为什么你不直接使用这个，避免使用助手？

public <T> void foo(List<T> l) {
    l.set(0, l.get(0));
}

我认为这个问题真的可以归结为：通配符和泛型有什么区别？所以，我去了这个：通配符和泛型之间的区别。它说使用类型参数：

1）如果你想对不同类型的方法参数强制执行某种关系，你不能用通配符来做到这一点，你必须使用类型参数。

但是，这不正是带有帮助函数的通配符实际在做的事情吗？它没有通过设置和获取未知值来强制不同类型的方法参数之间的关系吗？

我的问题是：如果你必须定义一些需要在不同类型的方法参数上建立关系的东西，那么为什么首先使用通配符，然后使用帮助函数呢？

这似乎是一种结合通配符的黑客方式。

Answer 1

你说得对，我们不必使用通配符版本。

这取决于哪个API看起来/感觉“更好”，这是主观的

    void foo(List<?> i) 
<T> void foo(List<T> i)

我会说第一个版本更好。

如果有界限

    void foo(List<? extends Number> i) 
<T extends Number> void foo(List<T> i)

第1个版本看起来更紧凑；类型信息都在一个位置。

在这个时候，通配符版本是惯用的方式，程序员更熟悉它。

JDK方法定义中有很多通配符，尤其是在java8引入lambda/Stream之后。诚然，它们非常丑陋，因为我们没有方差类型。但是试想一下，如果我们将所有通配符扩展到vars类型，情况会变得多么糟糕。

Answer 2

我同意：删除helper方法并键入公共API。没有理由不这样做，也没有理由不这样做。

总结一下通配符版本对助手的需求：虽然对我们人类来说很明显，但编译器不知道从l.get（0）返回的未知类型与列表本身的未知类型相同。也就是说，它没有考虑到set（）调用的参数来自与目标相同的列表对象，因此它必须是一个安全操作。它只注意到从get（）返回的类型是未知的，目标列表的类型是未知的，并且两个未知不能保证是同一类型。

Answer 3

在这种特殊情况下，这是因为列表。set（int，E）方法要求类型与列表中的类型相同。

如果没有helper方法，编译器就不知道是否有 与列表相同

The method set(int, capture#1-of ?) in the type List<capture#1-of ?> is not applicable for the arguments (int, capture#2-of ?)

对于helper方法，您告诉编译器，类型是相同的，我只是不知道类型是什么。

那么为什么有非辅助方法呢？

泛型直到Java 5才被引入，因此有很多代码早于泛型。Java 5之前的列表现在是一个列表