为什么我不能扩展接口“通用方法”并将其类型缩小到我的继承接口“class generic”? [英] Why can't I extend an interface "generic method" and narrow its type to my inherited interface "class generic"?

查看:160
本文介绍了为什么我不能扩展接口“通用方法”并将其类型缩小到我的继承接口“class generic”?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我举出一个例子,我的意思是哪个更容易。
想象一下泛型类型C意味着颜色类型:因此对于
而言,视觉简化假设C是C extends Color


 界面屏幕{
< C>背景及LT c取代;渲染(平面C平面);
}

接口MonochromeScreen< C>扩展屏幕{
@Override
背景< C>渲染(平面C平面);
}

这会引发名称冲突编译错误,说明两者具有相同类型的擦除但不能覆盖。



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



它不会使感觉允许一个子方法覆盖作为一个方法范围的泛型,当它的父级强制在类级别的一致性,但我认为它另有:我的父接口可能有20个方法与不相关的泛型类型,但我的子类会强制它们全部与非不兼容的额外规格/合同相同(这是任何扩展接口所做的),毕竟,单色sccreen仍然是一个屏幕,因为它可以用任何颜色绘制,我只是强制执行这种颜色,无论是哪一种,都要与儿童的其他功能保持一致,只是缩小了课堂层面的可能性,而不是方法层面。



是否有任何根本错误的假设来考虑这个功能?编辑:我接受Sotirios Delimanolis回答他非常聪明地发现了正确的麻烦,我并没有要求解决方案,但对于那些想要知道如何克服这种情况的人来说,我的答案中有一个技巧可以解释。

解决方案

以下是这里的细节:

  MonochromeScreen<红色和GT; redScreen = ...; 
屏幕redScreenJustAScreen = redScreen;
平面< Blue> bluePlane = null;
redScreenJustAScreen。< Blue> render(bluePlane);

如果你的建议是在编译时工作的,那么上面的代码片段可能必须在运行时失败 ClassCastException 因为由 redScreenJustAScreen 引用的对象期望平面< Red> ,但收到了 Plane< Blue>



泛型适用于所有应用,发生。如果允许这样的压倒一切的规则,泛型会失败。



我不太了解您的用例,但似乎并不需要泛型。


I show an example of what I mean which, is easier. Imagine the generic type C means Color type: So for visual simplification assume C is C extends Color

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

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

This would throw a name clash compilation error explaining that both have the same type erasure but are not overridable.

But I cannot understand why we could not simply allow overriding the signature as long as it is more restrictive. I mean, after all, the only difference is the scope of the generic type, in Screen is method-wide and in MonochromeScreen is class-wide.

It would not make sense to allow a child method to override as a method-scoped generic when its parent enforces coherence at class level, but I think it does otherwise: My parent interface could have 20 methods with unrelated generic types, but my child class would force them all to be the same as a non-incompatible extra specification/contract (which is what any extended interface does), After all, a monochrome sccreen is still an screen, as it can be painted with any color, I am just enforcing that color, whichever it is, to be it consistent accross the other functions of the child, Just narrowing the possibilities at class level, not method level.

Is there any fundamentally wrong assumption for considering the feature?

EDIT: I accepted Sotirios Delimanolis answer for him spotted the right trouble very cleverly and I was not asking for a solution, but for those who want to know how to overcome the situation there is a trick explained in my own answered answer

解决方案

Here's where this breaks:

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

If what you suggested worked at compile time, the snippet above would presumably have to fail at runtime with a ClassCastException because the object referenced by redScreenJustAScreen expects a Plane<Red> but received a Plane<Blue>.

Generics, used appropriately, are supposed to prevent the above from happening. If such overriding rules were allowed, generics would fail.

I don't know enough about your use case, but it doesn't seem like generics are really needed.

这篇关于为什么我不能扩展接口“通用方法”并将其类型缩小到我的继承接口“class generic”?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆