Generics는 Java SE 5.0에 도입된 기능입니다. 이 언어 기능이 등장한 지 수년이 지나면서 거의 모든 Java 프로그래머가 이 기능을 들어봤을 뿐만 아니라 사용해 본 적이 있을 것입니다. 무료 또는 무료가 아닌 Java 제네릭에 대한 튜토리얼이 많이 있습니다. 제가 본 최고의 교과서는 다음과 같습니다.
The Java Tutorial
Java Generics and Collections, 저자: Maurice Naftalin 및 Philip Wadler
Effective Java Chinese Edition(2nd Edition), Joshua Bloch 저.
풍부한 정보가 너무 많지만 때로는 너무 많다는 느낌이 들 때가 있습니다. 의 프로그래머는 여전히 Java 제네릭의 기능과 중요성을 잘 이해하지 못합니다. 그렇기 때문에 프로그래머가 Java 제네릭에 대해 알아야 할 가장 기본적인 사항을 가장 간단한 형식으로 요약하고 싶었습니다.
Java 제네릭의 동기
Java 제네릭을 이해하는 가장 쉬운 방법은 Java 제네릭을 일부 Java 유형 변환(캐스팅) 작업을 절약할 수 있는 편리한 구문으로 생각하는 것입니다.
List<Apple> box = ...; Apple apple = box.get(0);
위 코드 자체는 매우 명확하게 표현됩니다. box는 Apple 개체를 포함하는 목록입니다. get 메소드는 Apple 객체 인스턴스를 반환하며 이 프로세스에서는 유형 변환이 필요하지 않습니다. 제네릭이 없으면 위 코드를 다음과 같이 작성해야 합니다.
List box = ...; Apple apple = (Apple) box.get(0);
분명히 제네릭의 주요 이점은 컴파일러가 매개변수의 유형 정보를 유지하고 유형 검사를 수행하고 유형을 수행할 수 있다는 것입니다. 변환 작업: 컴파일러 이러한 유형 변환의 절대적인 정확성이 보장됩니다.
프로그래머에게 의존하여 객체 유형을 기억하고 유형 변환을 수행하는 대신(디버깅 및 해결이 어려운 프로그램 런타임 오류가 발생할 수 있음) 컴파일러는 프로그래머가 오류를 찾기 위해 많은 유형 검사를 수행하도록 도울 수 있습니다.
제네릭의 구성
제네릭의 구성에는 유형 변수의 개념이 도입됩니다. Java 언어 사양에 따르면 유형 변수는 다음 상황에서 발생하는 무제한 식별자입니다.
일반 클래스 선언
일반 인터페이스 선언
일반 메서드 선언
일반 생성자 선언
일반 클래스 및 인터페이스
클래스나 인터페이스에 하나 이상의 유형 변수가 있는 경우 이는 일반입니다. 유형 변수는 꺾쇠 괄호로 구분되며 클래스 또는 인터페이스 이름 뒤에 배치됩니다.
public interface List<T> extends Collection<T> { ... }
간단히 말해서 유형 변수의 역할은 유형 검사를 위해 컴파일러에 정보를 제공하는 매개변수와 같습니다.
전체 Collection 프레임워크 등 Java 클래스 라이브러리의 많은 클래스가 일반 클래스로 수정되었습니다. 예를 들어 위 코드의 첫 번째 부분에서 사용한 List 인터페이스는 일반 클래스입니다. 해당 코드에서 box는 Apple 유형의 변수가 있는 List 인터페이스의 클래스 구현 인스턴스인 List
사실 이 새로운 일반 태그 또는 이 List 인터페이스의 get 메소드는 다음과 같습니다.
T get(int index);
실제로 반환되는 get 메소드는 객체입니다. T 유형이고 T는 List
일반 메소드 및 생성자(생성자)
는 매우 유사합니다. 메소드 및 생성자 변수에 하나 이상의 유형이 선언되면 일반적일 수도 있습니다.
public static <t> T getFirst(List<T> list)
이 메소드는 List
예제
Java 클래스 라이브러리에서 제공하는 제네릭 클래스를 사용할 수도 있고, 자체 제네릭 클래스를 사용할 수도 있습니다.
유형 안전 쓰기 데이터...
다음 코드는 List
List<String> str = new ArrayList<String>(); str.add("Hello "); str.add("World.");
List
str.add(1); // 不能编译
유형 안전 데이터 읽기...
List
String myString = str.get(0);
클래스 라이브러리 탐색 Iterator
for (Iterator<String> iter = str.iterator(); iter.hasNext();) { String s = iter.next(); System.out.print(s); }
foreach 사용
"foreach" 구문도 제네릭의 이점을 누릴 수 있습니다. 이전 코드는 다음과 같이 작성할 수 있습니다.
for (String s: str) { System.out.print(s); }
이는 읽고 유지하기 쉽습니다.
Autoboxing 및 Autounboxing
Java 제네릭을 사용할 때 다음 코드와 같이 autoboxing/autounboxing의 두 가지 기능이 자동으로 사용됩니다.
List<Integer> ints = new ArrayList<Integer>(); ints.add(0); ints.add(1); int sum = 0; for (int i : ints) { sum += i; }
하지만 한 가지 알아두셔야 할 점은 캡슐화와 캡슐화 해제는 성능 저하를 가져오므로 전반적인 사용에 주의하시기 바랍니다.
하위 유형
Java에서는 객체 지향 유형을 사용하는 다른 언어와 마찬가지로 유형 계층 구조를 다음과 같이 설계할 수 있습니다.
在Java中,类型T的子类型既可以是类型T的一个扩展,也可以是类型T的一个直接或非直接实现(如果T是一个接口的话)。因为“成为某类型的子类型”是一个具有传递性质的关系,如果类型A是B的一个子类型,B是C的子类型,那么A也是C的子类型。在上面的图中:
FujiApple(富士苹果)是Apple的子类型
Apple是Fruit(水果)的子类型
FujiApple(富士苹果)是Fruit(水果)的子类型
所有Java类型都是Object类型的子类型。
B类型的任何一个子类型A都可以被赋给一个类型B的声明:
Apple a = ...; Fruit f = a;
泛型类型的子类型
如果一个Apple对象的实例可以被赋给一个Fruit对象的声明,就像上面看到的,那么,List
答案会出乎你的意料:没有任何关系。用更通俗的话,泛型类型跟其是否子类型没有任何关系。
这意味着下面的这段代码是无效的:
List<Apple> apples = ...; List<Fruit> fruits = apples;
下面的同样也不允许:
List<Apple> apples; List<Fruit> fruits = ...; apples = fruits;
为什么?一个苹果是一个水果,为什么一箱苹果不能是一箱水果?
在某些事情上,这种说法可以成立,但在类型(类)封装的状态和操作上不成立。如果把一箱苹果当成一箱水果会发生什么情况?
List<Apple> apples = ...; List<Fruit> fruits = apples; fruits.add(new Strawberry());
如果可以这样的话,我们就可以在list里装入各种不同的水果子类型,这是绝对不允许的。
另外一种方式会让你有更直观的理解:一箱水果不是一箱苹果,因为它有可能是一箱另外一种水果,比如草莓(子类型)。
这是一个需要注意的问题吗?
应该不是个大问题。而程序员对此感到意外的最大原因是数组和泛型类型上用法的不一致。对于泛型类型,它们和类型的子类型之间是没什么关系的。而对于数组,它们和子类型是相关的:如果类型A是类型B的子类型,那么A[]是B[]的子类型:
Apple[] apples = ...; Fruit[] fruits = apples;
可是稍等一下!如果我们把前面的那个议论中暴露出的问题放在这里,我们仍然能够在一个apple类型的数组中加入strawberrie(草莓)对象:
Apple[] apples = new Apple[1]; Fruit[] fruits = apples; fruits[0] = new Strawberry();
这样写真的可以编译,但是在运行时抛出ArrayStoreException异常。因为数组的这特点,在存储数据的操作上,Java运行时需要检查类型的兼容性。这种检查,很显然,会带来一定的性能问题,你需要明白这一点。
重申一下,泛型使用起来更安全,能“纠正”Java数组中这种类型上的缺陷。
现在估计你会感到很奇怪,为什么在数组上会有这种类型和子类型的关系,我来给你一个《Java Generics and Collections》这本书上给出的答案:如果它们不相关,你就没有办法把一个未知类型的对象数组传入一个方法里(不经过每次都封装成Object[]),就像下面的:
void sort(Object[] o);
泛型出现后,数组的这个个性已经不再有使用上的必要了(下面一部分我们会谈到这个),实际上是应该避免使用。
通配符
在本文的前面的部分里已经说过了泛型类型的子类型的不相关性。但有些时候,我们希望能够像使用普通类型那样使用泛型类型:
向上造型一个泛型对象的引用
向下造型一个泛型对象的引用
向上造型一个泛型对象的引用
例如,假设我们有很多箱子,每个箱子里都装有不同的水果,我们需要找到一种方法能够通用的处理任何一箱水果。更通俗的说法,A是B的子类型,我们需要找到一种方法能够将C类型的实例赋给一个C类型的声明。
为了完成这种操作,我们需要使用带有通配符的扩展声明,就像下面的例子里那样:
List<Apple> apples = new ArrayList<Apple>(); List<? extends Fruit> fruits = apples;
“? extends”是泛型类型的子类型相关性成为现实:Apple是Fruit的子类型,List
向下造型一个泛型对象的引用
现在我来介绍另外一种通配符:? super。如果类型B是类型A的超类型(父类型),那么C 是 C super A> 的子类型:
List<Fruit> fruits = new ArrayList<Fruit>(); List<? super Apple> = fruits;
为什么使用通配符标记能行得通?
原理现在已经很明白:我们如何利用这种新的语法结构?
? extends
让我们重新看看这第二部分使用的一个例子,其中谈到了Java数组的子类型相关性:
Apple[] apples = new Apple[1]; Fruit[] fruits = apples; fruits[0] = new Strawberry();
就像我们看到的,当你往一个声明为Fruit数组的Apple对象数组里加入Strawberry对象后,代码可以编译,但在运行时抛出异常。
现在我们可以使用通配符把相关的代码转换成泛型:因为Apple是Fruit的一个子类,我们使用? extends 通配符,这样就能将一个List
List<Apple> apples = new ArrayList<Apple>(); List<? extends Fruit> fruits = apples; fruits.add(new Strawberry());
这次,代码就编译不过去了!Java编译器会阻止你往一个Fruit list里加入strawberry。在编译时我们就能检测到错误,在运行时就不需要进行检查来确保往列表里加入不兼容的类型了。即使你往list里加入Fruit对象也不行:
fruits.add(new Fruit());
你没有办法做到这些。事实上你不能够往一个使用了? extends的数据结构里写入任何的值。
原因非常的简单,你可以这样想:这个? extends T 通配符告诉编译器我们在处理一个类型T的子类型,但我们不知道这个子类型究竟是什么。因为没法确定,为了保证类型安全,我们就不允许往里面加入任何这种类型的数据。另一方面,因为我们知道,不论它是什么类型,它总是类型T的子类型,当我们在读取数据时,能确保得到的数据是一个T类型的实例:
Fruit get = fruits.get(0);
? super
使用 ? super 通配符一般是什么情况?让我们先看看这个:
List<Fruit> fruits = new ArrayList<Fruit>(); List<? super Apple> = fruits;
我们看到fruits指向的是一个装有Apple的某种超类(supertype)的List。同样的,我们不知道究竟是什么超类,但我们知道Apple和任何Apple的子类都跟它的类型兼容。既然这个未知的类型即是Apple,也是GreenApple的超类,我们就可以写入:
fruits.add(new Apple()); fruits.add(new GreenApple());
如果我们想往里面加入Apple的超类,编译器就会警告你:
fruits.add(new Fruit()); fruits.add(new Object());
因为我们不知道它是怎样的超类,所有这样的实例就不允许加入。
从这种形式的类型里获取数据又是怎么样的呢?结果表明,你只能取出Object实例:因为我们不知道超类究竟是什么,编译器唯一能保证的只是它是个Object,因为Object是任何Java类型的超类。
存取原则和PECS法则
总结 ? extends 和 the ? super 通配符的特征,我们可以得出以下结论:
如果你想从一个数据类型里获取数据,使用 ? extends 通配符
如果你想把对象写入一个数据结构里,使用 ? super 通配符
如果你既想存,又想取,那就别用通配符。
这就是Maurice Naftalin在他的《Java Generics and Collections》这本书中所说的存取原则,以及Joshua Bloch在他的《Effective Java》这本书中所说的PECS法则。
Bloch提醒说,这PECS是指”Producer Extends, Consumer Super”,这个更容易记忆和运用。
以上就是Java泛型简明教程的内容,更多相关内容请关注PHP中文网(m.sbmmt.com)!