我展示了一个简单的例子。想象一下通用类型C表示颜色类型：因此，为了简化视觉，假设C是C扩展颜色
interface Screen {
<C> Background<C> render(Plane<C> plane);
}
interface MonochromeScreen<C> extends Screen{
@Override
Background<C> render(Plane<C> plane);
}
这将引发名称冲突编译错误，解释为两者具有相同的类型擦除但不可覆盖。
但是我不明白为什么我们不能简单地允许覆盖签名，只要它更具限制性。我的意思是，毕竟，唯一的区别是泛型类型的范围，在Screen中是方法范围的，而在MonochromeScreen是类范围的。
当父方法在类级别强制执行一致性时，允许将子方法覆盖为方法范围的泛型是没有意义的，但是我认为是这样的：我的父接口可能有20个具有不相关泛型类型的方法，但是我的子类会迫使它们全部与不兼容的额外规范/合同相同（这是任何扩展接口的作用），毕竟，单色滤网仍然是一个屏幕，因为它可以用任何颜色进行绘制，我只是强制使用该颜色（无论是哪种颜色），使其与孩子的其他功能保持一致，只是缩小类级别而不是方法级别的可能性。
考虑该功能是否存在根本错误的假设？
编辑：我接受了Sotirios Delimanolis的回答，他非常聪明地发现了正确的问题，我不是在寻求解决方案，但是对于那些想知道如何克服这种情况的人，我自己的回答中有一个窍门
这是中断的地方：
MonochromeScreen<Red> redScreen = ...;
Screen redScreenJustAScreen = redScreen;
Plane<Blue> bluePlane = null;
redScreenJustAScreen.<Blue>render(bluePlane);
如果您建议的内容在编译时有效，则上面的代码片段在运行时可能必须失败，ClassCastException因为所引用的对象redScreenJustAScreen期望aPlane<Red>却收到了Plane<Blue>。
适当地使用泛型，可以防止上述情况的发生。如果允许此类覆盖规则，则泛型将失败。
对于您的用例，我还不太了解，但似乎并不是真的需要泛型。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句