Java 泛型:非法前向引用
给定一个通用接口,
interface Foo<A, B> { }
我想编写一个实现,要求 A 成为 B 的子类。所以我想做
class Bar<A, B super A> implements Foo<A, B> { }
// --> Syntax error
or
class Bar<A extends B, B> implements Foo<A, B> { }
// --> illegal forward reference
但似乎唯一有效的解决方案是:
class Bar<B, A extends B> implements Foo<A, B> { }
这有点难看,因为它颠倒了通用参数。
对于这个问题有什么解决方案或解决方法吗?
Given a generic interface
interface Foo<A, B> { }
I want to write an implementation that requires A to be a subclass of B. So I want to do
class Bar<A, B super A> implements Foo<A, B> { }
// --> Syntax error
or
class Bar<A extends B, B> implements Foo<A, B> { }
// --> illegal forward reference
But the only solution that seems to work is this:
class Bar<B, A extends B> implements Foo<A, B> { }
which is kind of ugly, because it reverses the order of the generic parameters.
Are there any solutions or workarounds to this problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
由于这在 Java 中是不可能的,请尝试以不同的方式考虑
Bar
。当您为
Bar
,您首先指定父类,然后指定子类。这就是Bar
的工作原理。不要认为它是倒退的,而是认为它是前进的。自然应该在子级之前指定父级。您添加的这种附加关系是驱动参数顺序的因素,而不是底层接口。Since this isn't possible in Java, try to think of
Bar<B, A extends B>
differently.When you declare a variable for
Bar
, you're specifying the parent class first and then the child class. That's howBar
works. Don't think of it as being backwards - think of it as being forwards. The parent should naturally be specified before the child. This additional relationship you added is what drives the parameter order, not the underlying interface.看到这个问题后,我花了一点时间尝试了一些我认为可能有效的不同技术。例如,构建通用接口
ISuper
,然后使用Bar实现 ISuper
(以及具有子类和扩展而不是实现的类似技术),但这只会导致类型错误,Bar.java:1: type argument A is not在其范围内
。同样,我尝试创建一个方法private ;条 foo() { 返回这个; };
并从构造函数中调用它,但这只会导致有趣的类型错误消息Bar.java:2: 不兼容的类型
发现:酒吧
required: Bar
所以,不幸的是,我认为答案是否定的。显然,这不是您所希望的答案,但似乎正确的答案是这是不可能的。
After seeing this question, I spent a little bit trying some different techniques that I thought might work. For example, building a generic interface
ISuper<B,A extends B>
and then havingBar<A,B> implements ISuper<B,A>
(and a similar technique with a sub-class and extends rather than implements) but this just results in a type error,Bar.java:1: type parameter A is not within its bound
. Likewise, I tried creating a methodprivate <A extends B> Bar<A,B> foo() { return this; };
and calling it from the constructor, but this just results in the fun type error messageBar.java:2: incompatible types
found : Bar<A,B>
required: Bar<A,B>
So, I think that, unfortunately, the answer is no. Obviously, it's not the answer you were hoping for, but it seems that the correct answer is that this just isn't possible.
已经指出,既没有解决方案也没有好的解决方法。这就是我最终所做的。它仅适用于我的特殊情况,但如果您遇到类似问题,可以将其作为启发。 (这也解释了为什么我遇到这个问题)
首先,有这个类(仅显示相关接口):
Foo
接口实际上是类
Bar
应该像这样工作最简单的方法是像这样转换值:的实例。调用该对象会在某个时刻神秘地失败,但不会在实际发生错误的时刻失败。
p.setNext((Output) p.getNext())
。但这很糟糕,因为它允许创建 JustCopyIt
执行
class JustCopyIt;实现 Processor
在这里也不起作用,因为这样我就无法处理Pipe
。所以我最终所做的就是将接口更改为:
这样,JustCopyIt
就能够处理
Pipe
。虽然这在技术上似乎是唯一有效的解决方案,但它仍然很糟糕,因为它 1)仅适用于这种特殊情况,2)要求我更改接口(这并不总是可能的)以及 3)制作其他代码处理器丑陋。
编辑:
再次阅读基思的回答激发了我另一种解决方案:
It was pointed out already that there is neither a solution nor a nice workaround. Here is what I finally did. It only works for my special case, but you can take it as an inspiration if you run into similar problems. (It also explains why I ran into this problem)
First of all, there is this class (showing only the relevant interface):
The
Foo
interface is actuallyand the class
Bar
should work like thisThe easiest way would be to cast the values like this:
p.setNext((Output) p.getNext())
.But this is bad as it would allow to create an instance of
JustCopyIt<Integer, String>
. Calling this object would mysteriously fail at some point, but not at the point where the actual error is made.Doing
class JustCopyIt<Type> implements Processor<Type, Type>
would also not work here, because then I am not able to process aPipe<String, Object>
.So what I finally did was to change the interface to this:
This way, a
JustCopyIt<List>
is able to process aPipe<ArrayList, Collection>
.While this technically seems to be the only valid solution, it is still bad because it 1) only works for this special case, 2) required me to change the interface (which is not always possible) and 3) made the code of the other processors ugly.
Edit:
Reading Keiths answer again inspired me for another solution: