리플렉션
리플렉션 기능(java.lang.reflect)을 이용하면 임의의 클래스에 접근할 수 있다. 예를 들어 Class 객체가 주어지면 그 클래스의 Constructor, Method, Field 인스턴스를 가져올 수 있고, 이어서 이 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다. 더 나아가서 Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있다. (저 인스턴스들을 통해 해당 클래스의 인스턴스를 생성하거나, 메서드를 호출하거나, 필드에 접근할 수 있음) 예를 들어 Method.invoke를 통해 어떤 객체의 메서드를 호출할 수 있다. 이렇게 리플렉션을 이용하면 컴파일 시점에 존재하지 않던 클래스도 동적으로 이용할 수 있다!
리플렉션의 단점
아래와 같은 명백한 단점이 있기 때문에 리플렉션 사용은 줄이는 방향으로 가야 한다.
사용해야할지 확신할 수 없다면 아마 필요 없을 것이다.
리플렉션 단점
1. 컴파일시점 타입 검사가 주는 이점을 전혀 누리지 못한다.
: 만약 프로그램이 리플렉션 기능을 써서 존재하지않는, 접근할수없는 메서드를 호출하려 하면, 런타임 오류가 발생한다.
2. 리플렉션을 이용하면 코드가 지저분 + 장황해진다.
3. 성능이 떨어진다.
: 리플렉션을 통한 메서드 호출은 일반 호출보다 훨씬 느리다.
리플렉션은 아주 제한된 형태로만 사용해야 이러한 단점을 피하고 이점만 취할 수 있다.
만약 컴파일시점에 이용할 수 없는 클래스를 사용해야만 한다면.. 비록 컴파일시점이라도 적절한 인터페이스나 상위 클래스를 이용할 수는 있을 것이다(Item64) 그게 가능하다면, 리플렉션은 인스턴스 생성에만 쓰고, 참조할 때는 인터페이스나 상위 클래스로 참조하자. 다음은 그 예시다.
public static void main(String[] args) {
// 아래 코드는 Set<String> 인터페이스인 인스턴스를 생성할 것이다.
// 클래스 이름을 Class 객체로 변환
Class<? extends Set<String>> cl = null;
try {
cl = (Class<? extends Set<Stirng>>) // 비검사 형변환!
Class.forName(args[0]); // 정확한 클래스는 명령줄의 첫번째 인수로 넣어줬다고 하자.
} catch (ClalssNotFoundException 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을 구현하지 않은 클래스입니다.");
}
// 생성한 집합을 사용한다.
// 두번째 이후의 인수들을 집합에 추가한 뒤 화면에 출력하기
// → 인수들이 출력되는 순서는, 아까 첫 번째로 지정한 인수인 '클래스'가 무엇이냐에 따라 달라진다.
// 만약 java.util.HashSet을 지정하면 무작위 순서일 것이고,
// 만약 java.util.TreeSet을 지정하면 알파벳 순서로 출력될 것이다.
s.addAll(Arrays.asList(args).subList(1, args.length));
System.out.println(s);
}
private static void fatalError(String msg) {
System.err.println(msg);
System.exit(1);
}
*참고: 위 코드는 '제네릭 집합 테스터'로 응용 가능하다. 그게 뭐냐면, 명시한 Set 구현체를 공격적으로 조작해보며 Set 규약을 잘 지키는지 검사해볼 수 있다.
*참고: 리플렉션 예외를 각각 잡는 대신, 모든 리플렉션 예외의 상위 클래스인 ReflectiveOperationException을 잡도록 하여 코드 길이를 줄일 수 있다.
*참고: 이 프로그램을 컴파일하면 비검사 형변환 경고가 뜬다. 하지만 Class<? extends Set<String>>으로의 형변환은 심지어 명시한 클래스가 Set을 구현하지 않았더라도 성공할 것이라서 실제 문제로 이어지지는 안는다. 단, 그 클래스의 인스턴스를 '생성하려 할 때' ClassCastException을 던지게 된다. 이 경고를 숨기는 방법은 (Item27)을 참고.
위 예시는 리플렉션의 단점 두 가지를 보여준다.
*두 단점 모두 객체를 생성하는 부분에만 국한된다. 객체가 일단 만들어지면, 그 후의 코드는 그냥 Set 인스턴스 사용할 때랑 똑같다.
1. 런타임에 총 여섯 가지나 되는 예외가 나온다.
ex: 명령줄 인수를 잘못 입력해본다면, 이 여섯가지 예외를 모두 발생시킬 수 있다.
2. 클래스 이름만으로 인스턴스를 생성해내기 위해 무려 25줄의 코드를 작성했다.
: 리플렉션이 안쓴다면 생성자 호출 한 줄로 끝날 것을!
핵심
리플렉션은 복잡한 특수 시스템을 개발할 때 필요한 강력 기능이지만 단점도 많다. 되도록 객체 생성에만 사용하고, 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환해 사용해야 한다.
'JAVA > Effective Java' 카테고리의 다른 글
[이펙티브 자바] 최적화는 신중히 사용하라 ─ 9장:일반적인 프로그래밍 원칙:Item67 (0) | 2023.10.22 |
---|---|
[이펙티브 자바] 네이티브 메서드는 신중히 사용하라 ─ 9장:일반적인 프로그래밍 원칙:Item66 (0) | 2023.10.22 |
[이펙티브 자바] 객체는 인터페이스를 사용해 참조하라 ─ 9장:일반적인 프로그래밍 원칙:Item64 (0) | 2023.10.21 |
[이펙티브 자바] 문자열 연결은 느리니 주의하라 ─ 9장:일반적인 프로그래밍 원칙:Item63 (0) | 2023.10.21 |
[이펙티브 자바] 다른 타입이 적절하다면 문자열 사용을 피하라 ─ 9장:일반적인 프로그래밍 원칙:Item62 (0) | 2023.10.20 |