리플렉션이란?
리플렉션 기능(java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다.
- Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있다.
- Constructor, Method, Field 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다.
- Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있다.
단점
- 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다.
- 예외 검사의 이점도 누릴 수 없다.
- 리플렉션 기능을 써서 존재하지 않는(접근할 수 없는) 메서드를 호출하려 시도하면 런타임 오류가 발생한다.
- 리플렉션을 이용하면 코드가 지저분하고 장황해진다.
- 성능이 떨어진다.
코드 분석 도구나 의존관계 주입 프레임워크처럼 리플렉션을 써야 하는 복잡한 애플리케이션이 몇 가지 있다.
- 하지만 이런 도구들도 명백한 단점으로 인해 리플렉션 사용을 점차 줄이고 있다.
[Why]
public static void main(String[] args) {
// 클래스 이름을 Class 객체로 변환
Class<? extends Set<String>> cl = null;
try {
cl = (Class<? extends Set<String>>) Class.forName(args[0]); // 비검사 형변환!
} catch (ClassNotFoundException e) {
fatalError("클래스를 찾을 수 없습니다.");
}
// 생성자를 얻는다.
Constructor<? extends Set<String>> cons = null;
try {
cons = cl.getDeclaredConstructor();
} catch (NoSuchMethodException e) {
fatalError("매개변수 없는 생성자를 찾을 수 없습니다.");
}
// 집합의 인스턴스를 만든다.
Set<String> s = null;
try {
s = cons.newInstance();
} catch (IllegalAccessException e) {
fatalError("생성자에 접근할 수 없습니다.");
} catch (InstantiationException e) {
fatalError("클래스를 인스턴스화할 수 없습니다.");
} catch (InvocationTargetException e) {
fatalError("생성자가 예외를 던졌습니다: " + e.getCause());
} catch (ClassCastException e) {
fatalError("Set을 구현하지 않은 클래스입니다.");
}
// 생성한 집합을 사용한다.
s.addAll(Arrays.asList(args).subList(1, args.length));
System.out.println(s);
}
private static void fatalError(String msg) {
System.out.println(msg);
System.exit(1);
}
코드 설명
- 위 프로그램은 Set<String> 인터페이스의 인스턴스를 생성하는데, 정확한 클래스는 명령줄의 첫 번째 인수로 확정한다.
- 그리고 생성한 집합(Set)에 두 번째 이후의 인수들을 추가한 다음 화면에 출력한다.
- 첫 번째 인수와 상관없이 이후의 인수들에서 중복은 제거한 후 출력한다.
- 인수들이 출력되는 순서는 첫 번째 인수로 지정한 클래스가 무엇이냐에 따라 달라진다.
java.util.HashSet은 무작위, java.util.TreeSet은 알파벳 순서
위 프로그램에서 볼 수 있는 리플렉션의 단점 두 가지
- 첫 번째, 런타임에 총 여섯 가지나 되는 예외를 던질 수 있다.
- 그 모두가 인스턴스를 리플렉션 없이 생성했다면 컴파일타임에 잡아낼 수 있었을 예외들이다.
- 참고로, 모든 리플렉션 예외의 상위 클래스인 ReflectiveOperationException을 사용하여 코드 길이를 줄일 수도 있다.
- 두 번째, 클래스 이름만으로 인스턴스를 생성해내기 위해 무려 25줄이나 되는 코드를 작성했다.
- 리플렉션이 아니라면 생성자 호출 한 줄로 끝났을 일이다.
- 두 단점 모두 객체를 생성하는 부분에만 국한된다.
- 객체가 일단 만들어지면 그 후의 코드는 여타의 Set 인스턴스를 사용할 때와 똑같다.
- 그래서 실제 프로그램에서는 이런 제약에 영향받는 코드는 일부에 지나지 않는다.
형변환 경고
- 위 프로그램을 컴파일하면 비검사 형변환 경고가 뜬다.
- 하지만 Class<? extends Set<String>>으로의 형변환은 심지어 명시한 클래스가 Set을 구현하지 않았더라도 성공할 것이라, 실제 문제로 이어지지는 않는다.
- 단, 그 클래스의 인스턴스를 생성하려 할 때 ClassCastException을 던지게 된다.
이 경고를 숨기는 방법은 아이템27 참고.
[When]
리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할 때 적합할 수 있다.
- 이 기법은 버전이 여러 개 존재하는 외부 패키지를 다룰 때 유용하다.
- 가동할 수 있는 최소한의 환경, 즉 주로 가장 오래된 버전만을 지원하도록 컴파일한 후, 이후 버전의 클래스와 메서드 등은 리플렉션으로 접근하는 방식이다.
[How]
리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점만 취할 수 있다.
- 컴파일타임에 사용할 수 없는 클래스를 사용해야만 하는 리플렉션 프로그램은 비록 컴파일타임이라도 인터페이스나 상위 클래스를 이용할 수는 있을 것이다. (아이템64)
- 다행히 이런 경우라면 리플렉션은 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용하자.