去哪个网站做吃播,广州网站开发创意设计公司,网站改版方案流程,中山 环保 骏域网站建设专家【0】README
0.1#xff09;以下内容转自#xff1a; http://www.cnblogs.com/ggjucheng/p/3352519.html 【1】泛型约束和局限性—— 类型擦除所带来的麻烦
1.1#xff09;继承泛型类型的多态麻烦。#xff08;—— 子类没有覆盖住父类的方法 #xff09;
看看下面这个…【0】README
0.1以下内容转自 http://www.cnblogs.com/ggjucheng/p/3352519.html 【1】泛型约束和局限性—— 类型擦除所带来的麻烦
1.1继承泛型类型的多态麻烦。—— 子类没有覆盖住父类的方法
看看下面这个类SonPair
class SonPair extends PairString{ public void setFirst(String fir){....}
}
很明显程序员的本意是想在SonPair类中覆盖父类Pair的setFirst(T fir)这个方法。但事实上SonPair中的setFirst(String fir)方法根本没有覆盖住Pair中的这个方法。 原因很简单Pair在编译阶段已经被类型擦除为Pair了它的setFirst方法变成了setFirst(Object fir)。 那么SonPair中setFirst(String)当然无法覆盖住父类的setFirst(Object)了。 这对于多态来说确实是个不小的麻烦我们看看编译器是如何解决这个问题的。编译器 会自动在 SonPair中生成一个桥方法(bridge method )
public void setFirst(Object fir)
{setFirst((String) fir)
}
这样,SonPair的桥方法确实能够覆盖泛型父类的setFirst(Object) 了。而且桥方法内部其实调用的是子类字节setFirst(String)方法。对于多态来说就没问题了。
1.2问题还没有完多态中的方法覆盖是可以了但是桥方法却带来了一个疑问
现在假设 我们还想在 SonPair 中覆盖getFirst()方法呢
class SonPair extends PairString
{public String getFirst(){....}
}
由于需要桥方法来覆盖父类中的getFirst编译器会自动在SonPair中生成一个 public Object getFirst()桥方法。 干货——引入了桥方法该方法是编译器生成的不是程序员码出来的但是疑问来了SonPair中出现了两个方法签名一样的方法(只是返回类型不同) ①String getFirst() // 自己定义的方法②Object getFirst() // 编译器生成的桥方法 难道编译器允许出现方法签名相同的多个方法存在于一个类中吗事实上有一个知识点可能大家都不知道 ① 方法签名 确实只有方法名参数列表 。这毫无疑问② 我们绝对不能编写出方法签名一样的多个方法 。如果这样写程序编译器是不会放过的。这也毫无疑问③ 最重要的一点是 JVM会用参数类型和返回类型来确定一个方法。 一旦编译器通某种方式自己编译出方法签名一样的两个方法 (只能编译器自己来创造这种奇迹我们程序员却不能人为的编写这种代码)。JVM还是能够分清楚这些方法的前提是需要返回类型不一样。
1.3 泛型类型中的方法冲突
//在上面代码中加入equals方法
public class PairT{ public boolean equals(T value){ return (first.equals(value)); }
}
这样看似乎没有问题的代码连编译器都通过不了 【Error】 Name clash命名冲突: The method equals(T) of type Pair has the same erasure as equals(Object) of type Object but does not override it。
编译器说你的方法与Object中的方法冲突了。这是为什么?
开始我也不太明白这个问题觉得好像编译器帮助我们使得equals(T)这样的方法覆盖上了Object中的equals(Object)。经过大家的讨论我觉得应该这么解释这个问题 首先、我们都知道子类方法要覆盖必须与父类方法具有相同的方法签名方法名参数列表。而且必须保证子类的访问权限父类的访问权限。这是大家都知道的事实。然后、在上面的代码中当编译器看到Pair中的equals(T)方法时第一反应当然是equals(T)没有覆盖住父类Object中的equals(Object)了。接着、编译器将泛型代码中的T用Object替代擦除。突然发现擦除以后equals(T)变成了equals(Object)糟糕了这个方法与Object类中的equals一样了。基于开始确定没有覆盖这样一个想法编译器彻底的疯了(精神分裂)。然后得出两个结论①坚持原来的思想没有覆盖。但现在一样造成了方法冲突了。 ②写这程序的程序员疯了(哈哈)。再说了拿Pair对象和T对象比较equals就像牛头对比马嘴哈哈逻辑上也不通呀。
1.4没有泛型数组一说
PairString[] stringPairsnew PairString[10];
PairInteger[] intPairsnew PairInteger[10];
这种写法编译器会指定一个Cannot create a generic array of Pair的错误 我们说过泛型擦除之后Pair[]会变成Pair[]进而又可以转换为Object[];假设泛型数组存在那么
Object[0]stringPairs[0]; Ok
Object[1]intPairs[0]; Ok
这就麻烦了理论上将Object[]可以存储所有Pair对象但这些Pair对象是泛型对象他们的类型变量都不一样那么调用每一个Object[]数组元素的对象方法可能都会得到不同的记过也许是个字符串也许是整形这对于JVM可是无法预料的。记住 数组必须牢记它的元素类型也就是所有的元素对象都必须一个样泛型类型恰恰做不到这一点。即使Pair String,Pair Integer… 都是Pair类型的但他们还是不一样。
总结泛型代码与JVM
① 虚拟机中没有泛型只有普通类和方法。② 在编译阶段所有泛型类的类型参数都会被Object或者它们的限定边界来替换。(类型擦除)③ 在继承泛型类型的时候桥方法的合成是为了避免类型变量擦除所带来的多态灾难。
