제네릭의 형식 타입 인수 T 자리에는 임의의 타입이 올 수 있다. 그러다 보니 이 타입을 사용하는 모든 코드는 임의의 T 타입에 대해
적법해야 한다. 단 하나라도 특정한 타입을 가정한 코드는 컴파일할 수 없다. 앞서 예로 든 다음 메서드를 보자.
<T> T max(T a, T b) {
if
(a > b) {
return
a;
}
else {
return
b;
}
}
인수로 전달된 두 개의 객체 a와
b의 값을 비교하여 더 큰 값을 찾아 주는 상식적인 코드이다. 이 코드는 에러로 처리되는데
왜냐하면 > 연산자가 모든 타입에 대해 유효하지 않기 때문이다.
Human 타입의 객체 kim과 lee를 생성해
놓고 kim > lee로 비교하면 과연 어떤 기준으로 비교할지 애매하다.
이런 문제가 발생하는 이유는 T가 임의의 클래스여서 적용 범위가 너무
광범위하기 때문이다. 메서드의 본체 코드가 특정한 타입이나 그 서브 타입만을 대상으로 할 때는 타입
인수의 범위를 제한해야 한다. 사용할 수 있는 타입이 제한된 타입 인수를 바운드 타입(bound type)이라고 하며 다음과 같은 형식으로 지정한다.
<T extends
upper>
extends 키워드 다음에 제한을 둘 클래스나 인터페이스를 지정하면
지정한 타입이나 그 서브 타입만 올 수 있다. 즉 T extends
upper라는 표현식은 upper를 포함한 서브클래스만을 의미한다. upper가 인터페이스인 경우라도 바운드 타입을 지정할 때는
implements 키워드 대신 extends 키워드를 사용한다.
위의 메서드를 바운드 타입으로 제대로 작성해 보자. 둘 중 큰 값을
가려 내려면 두 값을 비교할 수 있어야 하며 그러기 위해서는 Comparable<T> 인터페이스를
구현해야 한다. 이 인터페이스의 compareTo 메서드는
두 값의 대소 관계에 따라 양수나 음수 또는 0을 리턴하여 값의 대소를 판단한다.
|
comparable |
실행결과 |
|
class JavaTest { static
<T extends Comparable<T>> T max(T a, T b) { if
(a.compareTo(b) > 0) { return
a; }
else { return
b; } } public
static void main(String[] args) { int
result = JavaTest.max(1, 2); System.out.println(result); } } |
2 |
max 메서드의 타입 인수로 T는
반드시 Comparable<T> 인터페이스를 구현한 타입이어야 한다. 제네릭 인터페이스를 구현하는 제네릭 클래스를 칭하다 보니 < > 괄호가
중첩되어 무척 복잡해 보인다. 심하면 3중으로 중첩되기도
해 가독성이 떨어지고 어렵다.
본체에서는 수치형만 비교하는 > 연산자 대신 객체에 대해서도
쓸 수 있는 compareTo 메서드로 두 객체의 대소를 비교한다.
main에서는 1과 2중 큰 값을 찾아 출력하는데
원래는 다음과 같이 메서드로 전달되는 실 타입 인수를 밝혀야 하지만 추론 가능하므로 생략했다.
int result = JavaTest.<Integer>max(1, 2);
Integer는 대소 비교가 가능하고 Comparable<T> 인터페이스를 구현하므로 max 메서드로
전달할 수 있으며 대부분의 수치형 타입은 이 인터페이스를 지원한다. Double이나 Float는 물론이고 String 객체에 대해서도 이 메서드를 호출할
수 있다. 그러나 다음 코드는 에러로 처리된다.
Human man = JavaTest.max(new Human(23, "연아"), new Human(34, "태희"));
Human 클래스의 객체는 서로 대소를 비교할 방법이 없기 때문이다. Human이 Comparable<T> 인터페이스를 구현하여
나이순으로 비교하는 메서드를 제공한다면 이 코드도 컴파일 가능하다.
바운드 타입을 사용하면 실 타입 인수가 제한되므로 허용되는 타입에 대해서는 메서드를 자유롭게 호출할 수 있다. 다음 코드를 보자.
class Human {
void
intro() { System.out.println("나 사람"); }
}
class Student extends Human {
void
intro() { System.out.println("나 학생"); }
}
class Box<T> {
T
value;
Box(T
value) { this.value = value; }
T
get() { return value; }
void
set(T value) { this.value = value; }
void
intro() {
value.intro();
}
}
사람과 학생 클래스가 있고 이 객체를 저장하는 Box 제네릭을 선언했다. Box는 사람이나 학생을 저장하며 소개를 출력하는 intro 메서드를
정의한다. 언뜻 보기에는 될 것 같지만 value.intro() 구문이
에러로 처리된다.
왜냐하면 Box의 형식 타입 인수
T는 바운드되지 않아 임의의 타입이 올 수 있는데 모든 클래스가 intro 메서드를 지원하지
않기 때문이다. 문제를 해결하려면 Box가 받아들이는 타입
인수 T를 intro 메서드를 지원하는 클래스로 제한한다.
|
bound |
실행결과 |
|
class Human { void
intro() { System.out.println("나 사람"); } } class Student extends Human { void
intro() { System.out.println("나 학생"); } } class Box<T extends Human> { T
value; Box(T
value) { this.value = value; } T
get() { return value; } void
set(T value) { this.value = value; } void
intro() { value.intro(); } } class JavaTest { public
static void main(String[] args) { Human
h = new Human(); Box<Human>
bh = new Box<Human>(h); bh.intro(); Student
s = new Student(); Box<Human>
bs = new Box<Human>(s); bs.intro(); } } |
나 사람 나 학생 |
Box가 받을 수 있는 타입을
Human 서브 클래스로 제한함으로써 이 클래스 내부에서 T타입의 intro 메서드를 이상 없이 호출할 수 있다. 다음 코드는 에러이다. String 클래스는 Human과는 아무런 연관이 없고 intro 메서드도 없어 Box에 저장할 수 없다.
Box<String> bs = new
Box<String>("문자열");
바운드 타입은 & 기호로 구분하여 여러 클래스나 인터페이스에
대해 지정할 수 있다. 여러 개의 바운드를 지정하면 목록의 모든 타입에 대한 서브 타입만 허용된다. 보통 클래스 하나와 인터페이스 여러 개를 바운드로 지정하는데 클래스가 목록의 제일 처음에 와야 한다. A, B, C 세 개의 타입을 바운드로 지정하고 싶다면 다음과 같이 한다.
<T extends A & B & C>
이렇게 되면 세 가지 타입을 모두 지원하는 경우로만 제한된다. A 클래스
또는 그 후손 클래스가 B, C 인터페이스를 지원해야만 T로
전달될 수 있다.
부모 타입의 객체가 자식 객체를 대입받을 수 있으며 이는 다형성의 근간이 되는 중요한 문법이다. 이 관계를 연구해 보기 위해 익숙한 클래스를 활용해 보자.
Human h = new Human();
Student s = new Student();
h = s;
//s = h;
상속 관계에 있는 Human과
Student 객체를 각각 생성한 상태에서 부모 타입 변수 h에 자식 타입 객체 s를 대입했다. h로 가능한 동작은
s로 모두 가능하여 합당한 대입이다. 그러나 반대의 대입인 s = h는 s가 가능한 모든 동작을 h가 다 지원하지 않아 불가능하다. 여기까지는 익히 잘 아는 내용이다. 그렇다면 제네릭의 경우는 어떨까?
Human h = new Human();
Student s = new Student();
Box<Human> bh = new Box<Human>(s);
Human을 저장하는 bh 객체에 Student 객체 s를 저장했다.
Student가 Human의 서브 타입이므로 이 코드도 합당하다. Box<Human>은 Human과 그 서브 타입 객체를
저장하기 때문이다. 단, 서브 타입 객체를 다시 읽을 때는
캐스팅이 필요하다.
Student kim = (Student)bh.get();
사실 생성자를 통해 필드에 대입하는 것은 객체끼리 대입하는 것과 같아 상속 관계의 객체끼리 대입하는 코드와 형태만
다를뿐 같은 코드라고 할 수 있다. 다음은 제네릭 타입의 경우를 보자.
여기서부터는 좀 복잡하고 헷갈린다.
Human h = new Human();
Student s = new Student();
Box<Human> bh = new Box<Human>(h);
Box<Student> bs = new Box<Student>(s);
//bh = bs;
Human을 저장하는 bh와 Student를 저장하는 bs 객체를 생성해 놓고 bh에 bs를 대입했다. 이
코드는 허락되지 않아 컴파일 에러로 처리된다. Human과
Student는 부모 자식 관계이지만 Box<Human>과 Box<Student>의 관계는 그렇지 않다.
실 타입 인수가 상속 관계여서 언뜻 생각하기에는 부모 자식 관계 같지만 두 클래스는 전혀 상관없으며 IS A 관계가 아니다. 이것이 제네릭에서 가장 이해하기 어려운 내용이며
왜 그런지 이유를 정확하게 이해해야 한다. bh = bs 대입이 가능해진다면 다음과 같은 코드를 작성할
수 있다.
bh.set(h);
Student k = bs.get();
bh 객체에 Human 객체를
저장하는 것은 당연히 가능하다. 그러나 bh가 실제로는 bs를 대입받았으므로 이때의 Human 객체는 bs에 저장된다. 이 상태에서 bs에
저장된 객체를 꺼낸다고 해 보자. bs는
Box<Student> 타입이므로 더 볼 것도 없이 Student 객체가 읽혀지며
따라서 Student 타입의 객체 k로 대입받았다.
그러나 불행히도 Student 객체에 저장된 것은 Human 타입의 h이며 여기서 캐스팅 예외가 발생하고 프로그램은
다운되어 버린다. 위의 두 코드는 논리적으로 아무 이상이 없지만 bh가 bs를 대입받도록 허락한 bh = bs 대입문이 문제의 원인이다. 이런 이유로 Box<Human>과 Box<Student>는 IS A 관계가 아니며 extends 키워드로 상속을 받은 것도 아니다.
Box가 너무 단순해서 잘 이해가 안된다면 실제 프로젝트에 사용되는
컬렉션으로 테스트해 보자. 아주 단순하게 만들었지만 상황이 복잡하므로 코드를 주의 깊게 봐야 한다.
|
gensubtype |
|
import java.util.ArrayList; class Human { } class Student extends Human { } class JavaTest { public
static void main(String[] args) { ArrayList<Human>
ah = new ArrayList<Human>(); ArrayList<Student>
as = new ArrayList<Student>(); ah.add(new
Human()); as.add(new
Student()); ah.add(new
Student()); //ah
= as; ah.add(new
Human()); Student
k = as.get(1); } } |
사람 배열 ah와 학생 배열 as를
생성하고 ah에 객체 2개,
as에 객체 하나만 저장했다. 여기서 세 번째 추가문은
ah 배열에 Student 객체를 저장했는데 아무 이상 없이 잘 저장된다. 왜냐하면 Human과
Student는 상속 관계이기 때문이다.
그러나 ah에 as를 대입하는
것은 안된다. 이 코드의 주석을 제거해 보면 다음과 같은 에러 메시지가 출력된다. ArrayList<Human>과
ArrayList<Student>는 상속 관계가 아니기 때문이다.
Type mismatch: cannot convert from
ArrayList<Student> to ArrayList<Human>
만약 ah = as 대입문이 허락된다면 ah를 통해 as에 Human 객체를
추가할 수 있으며 이는 Student만 저장하는
ArrayList<Student> 타입과 맞지 않다. 이런 잠재적인 위험이 있기
때문에 대입이 금지되어 있다.
여기까지 예제를 곁들여 상세하게 설명했지만 웬만큼 정신 집중을 하지 않으면 헷갈리기만 한다. 결론을 요약하자면 Child와
Parent가 상속 관계라 할지라도 Generic<Child>와 Generic<Parent>는 상속 관계가 아니다.
제네릭의 서브 타입 관계가 복잡하고 제약이 많아 좀 더 유연한 타입이 필요하다.
예를 들어 Box<Human>과
Box<Student>는 상속 관계가 아니지만 이 둘을 모두 받을 수 있는 메서드를 선언하고 싶다고 하자. 그러려면 Box의 실 타입 인수 자리에 Human으로부터 상속되는 임의 타입을 지정할 수 있어야 한다. 이
표현은 다음과 같다.
<? extends Human>
여기서 ?가 와일드 카드이며 알 수 없는 임의의 타입을 의미한다. 뒤쪽에 extends Human으로 제한되었으므로 Human으로부터 파생된 임의의 타입이라는 뜻이다.
|
wildcard |
실행결과 |
|
class Human { void
intro() { System.out.println("나 사람"); } } class Student extends Human { void
intro() { System.out.println("나 학생"); } } class Box<T> { T
value; Box(T
value) { this.value = value; } T
get() { return value; } void
set(T value) { this.value = value; } } class JavaTest { static
void printMan(Box<? extends Human> box) { box.get().intro(); } public
static void main(String[] args) { Human
h = new Human(); Box<Human>
bh = new Box<Human>(h); printMan(bh); Student
s = new Student(); Box<Student>
bs = new Box<Student>(s); printMan(bs); } } |
나 사람 나 학생 |
예제의 printMan 메서드는
Human 서브 타입을 저장하는 Box 객체 box를
받는다. 이 인수로 Box<Human>,
Box<Student> 등을 모두 전달받을 수 있다. 본체에서는 이 박스에 저장된
객체를 꺼내 intro 메서드를 호출한다. Box에 저장된
객체는 Human의 서브 타입이므로 intro 메서드를 안전하게
호출할 수 있다.
이처럼 extends 키워드로 부모를 제한하는 것을 위쪽 제한 와일드카드(upper bounded wildcard)라고 한다. 부모로부터 파생된
임의의 타입이 이 자리에 올 수 있다. 반대로 아래쪽 자식을 제한하는 것을 아래쪽 제한 와일드카드(lower bounded wildcard)라고 하는데 다음 형식으로 지정한다.
<? super child>
child 클래스의 모든 부모 타입이 이 자리에 올 수 있다. 예를 들어 Box<? super Student> 타입은 Student 자체는 물론이고 부모 타입인 Human, Object 등도
해당된다. Student 객체를 대입받을 수 있는 모든 타입을 다 허용한다는 뜻이다.
와일드 카드에 extends나
super 키워드를 쓰지 않고 <?> 기호만 사용하면 제한이 없는 와일드카드(unbounded wildcard)가 되며 알 수 없는 타입을 의미한다.
<?> 자리에 임의의 타입을 허용하되 이렇게 되면 특정 클래스의 메서드는 호출하지 못한다.
printMan을 다음과 같이 수정해 보자.
static void printMan(Box<?> box) {
box.get().intro();
}
inrto() 메서드가 존재하지 않는다는 에러 메시지가 출력된다. 알 수 없는 ? 타입에는
intro 메서드가 없다. 제한 없는 와일드 카드는 Object의 기능만 사용하거나 타입 인수의
기능을 전혀 필요치 않는 경우에 사용된다. 예를 들어
ArrayList<?>로 받아 size, clear 등의 메서드로 배열 자체만
조작한다면 요소의 타입이 무엇이건 상관없다.