有界类型参数

 

---

有界类型参数(Bounded Type Parameters)

 

你是否曾经想在一个参数化类型(parameterized type)里限制type argument的类型？比如一个只处理数字的方法只想接受Number或者其子类的实例。那么就靠有界类型参数可以实现啦。

声明有界类型参数，列出类型参数的名字，之后跟 extends 关键子，之后跟上界，本例中也就是Number。在本文中，extends表示的就是扩展(extends)一个class或者interface。

 

public class Box<T> {

private T t; 

public void set(T t) {
this.t = t;
}

public T get() {
return t;
}

public <U extends Number> void inspect(U u){
System.out.println("T: " + t.getClass().getName());
System.out.println("U: " + u.getClass().getName());
}

public static void main(String[] args) {
Box<Integer> integerBox = new Box<Integer>();
integerBox.set(new Integer(10));
integerBox.inspect("some text"); // error: this is still String!
}
}

 

这里编译就会错误，泛型方法里限制了上界为number，而我们调用该方法是还是用String。

 

另外，允许你调用上界的方法，比如可以调用Number的方法。下例显示可以调用Integer的方法

 

public class NaturalNumber<T extends Integer> {

private T n;

public NaturalNumber(T n) { this.n = n; }

public boolean isEven() {
return n.intValue() % 2 == 0;
}

// ...
}

 

在isEven方法里，我们调用了Integer的方法intValue（）

---

多个上界

上面之介绍了单个上界，实际中，类型参数可以有多个上界。

 

<T extends B1 & B2 & B3>

 

一个有多个上界的类型变量是这几个上界的子类型。如果其中一个上界是类，则必须先写，比如

 

Class A

interface B

interface C

class D <T extends A & B & C>

 

如果不先写A，在编译的时候会报错。

---

泛化方法和上界类型参数

上界类型参数是实现泛化算法的关键。看下面的方法：计算数组T[ ]里面比某一元素elem大的元素的数量

 

public static <T> int countGreaterThen(T[] anArray, T elem){

int count = 0;

for(T e: anArray){

if(e > elem) // compiler error

++count;

}

return count;

}

 

这里的方法实现非常明了，但是编译不通过。因为大于操作 > 只针对原始类型，比如short,int,long.double等等。你无法用> 去比较两个对象。去解决这个问题，让类型参数的上界为一个Comparable<T>接口

 

public interface Comparable<T>{

public int compareTo(T o);

}

最好代码改为：

 

public static <T extends Comparable<T>> int countGreaterThen(T[] anArray, T elem){

int count = 0;

for(T e: anArray){

if(e > elem)

++count;

}

return count;

}

---

---

     JDK1.5中引入了泛型(Generic)机制。泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。

     Java语言引入泛型的好处是安全简单，在编译的时候检查类型安全，并且所有的强制转换都是自动和隐式的，提高代码的重用率。

JAVA泛型的规则和限制
泛型的类型参数只能是类类型（包括自定义类），不能是简单类型。
同一种泛型可以对应多个版本（因为参数类型是不确定的），不同版本的泛型类实例是不兼容的。
泛型的类型参数可以有多个。
泛型的参数类型可以使用extends语句，例如<T extends superclass>。习惯上称为“有界类型”。
泛型的参数类型还可以是通配符类型。例如Class<?> classType = Class.forName(java.lang.String);
限制泛型的可用类型
    如果我们要限制class GenericsFoo<T>类型持有者T的范围为集合接口类型，只需使用class GenericsFoo<T extends Collection>，这样类中的泛型T只能是Collection接口的实现类，传入非Collection接口编译会出错。

通配符泛型
    为了解决类型不能动态根据实例来确定的缺点，引入了“通配符泛型”，使得一个参数可以用来表示一组实例化后的模板。

其中，

“?”代表未知类型

extends关键字声明了类型的上界，表示参数化的类型可能是所指定的类型，或者是此类型的子类

super关键字声明了类型的下界，表示参数化的类型可能是所指定的类型，或者是此类型的父类型，直至Object

上界
 

public void upperBound(List<? extends Date> list, Date date)  
{  
    Date now = list.get(0);  
    System.out.println("now==>" + now);  
    //list.add(date); //这句话无法编译  
    list.add(null);//这句可以编译，因为null没有类型信息  
}

 

无法编译的原因就在于，实际调用时传入的list可能是java.util.Date的某个子类的参数化类型，如: 

public void testUpperBound()  
{  
    List<Timestamp> list = new ArrayList<Timestamp>();  
    Date date = new Date();  
    upperBound(list,date);  
}

 

 

     也就是说，upperBound方法中实际的list是List<Timestamp>，向它添加一个基类Date类型，由于基类无法转换为子类，所以无法添加。相反，读取数据时，不管实际的list是什么类型，但可以知道它至少会返回一个Date类型，所以用foreach，get等没有问题。 

下界
    先看示例代码：

public void lowerBound(List<? super Timestamp> list)  
{  
    Timestamp now = new Timestamp(System.currentTimeMillis());  
    list.add(now);  
    //Timestamp time = list.get(0); //不能编译  
}  

 

不能编译的原因是调用代码可能是这样的：

public void testLowerBound()  
{  
    List<Date> list = new ArrayList<Date>();  
    list.add(new Date());  
    lowerBound(list);  
} 

    在lowerBound方法中的List<? super Timestamp>表示这个list的参数类型可能是Timestamp或Timestamp的父类，如后面的代码里，实际传入的是一个List<Date>类型。List<Date>中可以添加一个Timestamp对象，但list.get()方法返回的对象类型可能是Date甚至是Object，不能安全的向下转换到Timestamp，也就因此无法编译了。

 

    小结一下就是：上界add方法受限，下界get方法受限。

 

泛型方法
    是否拥有泛型方法，与其所在的类是否泛型没有关系。要定义泛型方法，只需将泛型参数列表置于返回值前。如：

public <T> void f(T x) {}

    使用泛型方法时，不必指明参数类型，编译器会自己找出具体的类型。泛型方法除了定义不同，调用就像普通方法一样。

 

    最后，需要注意的是，一个static方法，无法访问泛型类的类型参数，因为类还没有实例化，所以，若static方法需要使用泛型能力，必须使其成为泛型方法。
 

---

参考文献

https://blog.csdn.net/hybxiaodao/article/details/53136110

https://blog.csdn.net/daniel_h1986/article/details/5708605