java - 为什么我不能扩展接口(interface) "generic method"并将其类型缩小到继承的接口(interface) "class generic"？

Question

我举了一个例子来说明我的意思，这个例子更容易。 想象通用类型 C 表示颜色类型:所以对于 视觉简化假设 C 是 C 扩展 Color

interface Screen {
   <C> Background<C> render(Plane<C> plane);
}

interface MonochromeScreen<C> extends Screen{
       @Override
       Background<C> render(Plane<C> plane);  
}

这会引发名称冲突编译错误，解释两者具有相同的类型删除但不可覆盖。

但我不明白为什么我们不能简单地允许覆盖签名，只要它更具限制性。我的意思是，毕竟，唯一的区别是泛型类型的范围，在 Screen 中是方法范围，而在 MonochromeScreen 中是类范围。

当子方法的父方法在类级别强制执行一致性时，允许子方法重写为方法范围的泛型是没有意义的，但我认为否则会这样做:我的父接口(interface)可以有 20 个具有不相关泛型类型的方法，但是我的子类将强制它们全部与不兼容的额外规范/契约(Contract)相同(这是任何扩展接口(interface)所做的)，毕竟，单色屏幕仍然是屏幕，因为它可以用任何颜色绘制，我只是强制执行该颜色，无论它是什么，以使其在子项的其他功能中保持一致，只是缩小类级别而不是方法级别的可能性。

考虑该功能是否存在根本错误的假设？

编辑:我接受了 Sotirios Delimanolis 的回答，他非常聪明地发现了正确的问题，我并不是在寻求解决方案，但对于那些想知道如何克服这种情况的人，我自己解释了一个技巧已回答答案

Answer 1

这里是问题所在:

MonochromeScreen<Red> redScreen = ...;
Screen redScreenJustAScreen = redScreen;
Plane<Blue> bluePlane = null;
redScreenJustAScreen.<Blue>render(bluePlane);

如果您的建议在编译时有效，则上面的代码片段可能会在运行时失败，并显示 ClassCastException因为 redScreenJustAScreen 引用的对象预计 Plane<Red>但收到了Plane<Blue> .

正确使用泛型应该可以防止上述情况发生。如果允许这种压倒一切的规则，泛型就会失败。

我对您的用例了解不够，但似乎并不真正需要泛型。