리플렉션 (java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져오고, 이 인스턴스로 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다.
메서드 시그니쳐 : 메서드 이름과 매개변수 리스트 조합.
나아가서 이 인스턴스를 이용해, 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수 있다. 이 인스턴스로 해당 클래스의 인스턴스를 생성, 메서드 호출, 필드에 접근할 수 있다는 뜻이다. Method.invoke는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도 호출할 수 있게 해준다.
물론 단점이 있다.
컴파일타임 타입 검사의 이점을 누릴 수 없다.
프로그램이 리플렉션 기능을 써서 존재하지 않는 혹은 접근할 수 없는 메서드를 호출하려하면 런타임 오류가 발생한다.
코드가 지저분하고 장황해진다.
성능이 떨어진다.
일반 메서드 호출에 비해 훨씬 느리다.
🍑 본론
리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점을 취할 수 있다.
코드 분석 도구나 의존관계 주입 프레임워크처럼 리플렉션을 써야 하는 복잡한 어플리케이션들마저 리플렉션의 사용을 줄이고 있다. 리플렉션이 필요한가 확신할 수 없다면 아마 필요 없을 것이다.
컴파일 시점에 활용 불가능한 클래스를 사용해야 한다면 컴파일 시점이라도 적절한 인터페이스나 상위 클래스를 이용하면 가능할 것이다. 다행히 이런 경우라면 리플렉션은 인스턴스 생성에만 사용하고, 이렇게 생성한 인스턴스는 인터페이스나, 상위 클래스로 참조해 사용하자.
public class Main {
public static void main(String[] args) {
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);
} 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.err.println(msg);
System.exit(1);
}
}
위 코드는 넘어온 인자 첫번째(클래스)로 인스턴스를 생성 후, 나머지 인스턴스를 해당 인스턴스에 집어넣는 함수이다.
아래와 같이 인자를 전달하면 위 코드를 수행 후 다음과 같은 결과를 낸다.
java Main.java java.util.HashSet one two three
> [one, three, two]
Set 인터페이스를 구현하므로 중복은 제거한 후 값을 출력할 것이다. 하지만 어떤 Set 구현체를 사용하였느냐에 따라 출력 순서는 달라진다.
java.util.HashSet을 사용하면 출력 결과는 랜덤일 것이다. (JDK8 이후로는 HashSet 순서가 유지되게 구현되는 경우가 많음.)
java.util.TreeSet을 사용하면 출력 결과는 정렬될 것이다. (TreeSet은 내부 요소를 정렬한다.)
java Main.java java.util.TreeSet one two three four
> [four, one, three, two]
위 예시는 리플렉션의 단점 두 가지를 보여준다.
런타임에 총 여섯가지나 되는 예외를 던질 수 있다. 이 모두 인스턴스를 리플렉션 없이 사용했다면 컴파일 시점에 잡을 수 있을 예외들이다.
클래스 이름만으로 인스턴스를 생성하기 위해 무려 25줄이나 되는 코드를 작성했다. 리플렉션이 아니었다면 생성자 호출 한 줄로 끝났을 것이다.
물론 리플렉션 각각의 예외를 별도로 잡기 보다, 리플렉션 예외의 상위 클래스 ReflectiveOperationException을 잡도록 하여 코드 길이를 줄일 수도 있다.
두 단점 모두 객체를 생성하는 시점에 국한된다. 인스턴스 생성 후에는 생성자로 인스턴스를 생성했건, 리플렉션으로 인스턴스를 생성했건 무관하다.
이 프로그램을 컴파일하면 비검사 형변환 경고가 뜬다. 하지만 Class<? extends Set<String>> 으로의 형변환은 먕시한 클래스가 Set을 구현하지 않더라도 성고이할 것이라 문제가 되지는 않는다. 하지만, 해당 클래스의 인스턴스를 생성하는 부분에서 ClassCastException을 던질 것이다.
🍑 결론
리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드의 의존성을 관리할 때 적합하다. 이 기법은 버전이 여러 개 존재하는 다른 패키지를 다룰 때 유용하다. 가동할 수 있는 최소의 환경 (가장 초기 버전)을 지원하도록 컴파일한 후, 이후 추가된 클래스와 메서드는 리플렉션으로 접근하는 방식이다. 이렇게 하려면 접근하려는 새로운 클래스나 메서드가 런타임에 존재하지 않을 수 있다는 사실을 감안해야 한다.
위에 java.util.HashSet 같은 경우,
이런 식으로 hashCode() 작성하면 당연히 순서 랜덤으로 나옴
@Override
public int hashCode() {
return ThreadLocalRandom.current().nextInt();
}
Chapter : 9. 일반적인 프로그래밍 원칙
Item : 65. 리플렉션보다는 인터페이스를 사용하라
Assignee : youngkimi
🍑 서론
리플렉션 (java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져오고, 이 인스턴스로 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다.
나아가서 이 인스턴스를 이용해, 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수 있다. 이 인스턴스로 해당 클래스의 인스턴스를 생성, 메서드 호출, 필드에 접근할 수 있다는 뜻이다. Method.invoke는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도 호출할 수 있게 해준다.
물론 단점이 있다.
🍑 본론
리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점을 취할 수 있다.
코드 분석 도구나 의존관계 주입 프레임워크처럼 리플렉션을 써야 하는 복잡한 어플리케이션들마저 리플렉션의 사용을 줄이고 있다. 리플렉션이 필요한가 확신할 수 없다면 아마 필요 없을 것이다.
컴파일 시점에 활용 불가능한 클래스를 사용해야 한다면 컴파일 시점이라도 적절한 인터페이스나 상위 클래스를 이용하면 가능할 것이다. 다행히 이런 경우라면 리플렉션은 인스턴스 생성에만 사용하고, 이렇게 생성한 인스턴스는 인터페이스나, 상위 클래스로 참조해 사용하자.
위 코드는 넘어온 인자 첫번째(클래스)로 인스턴스를 생성 후, 나머지 인스턴스를 해당 인스턴스에 집어넣는 함수이다.
아래와 같이 인자를 전달하면 위 코드를 수행 후 다음과 같은 결과를 낸다.
Set 인터페이스를 구현하므로 중복은 제거한 후 값을 출력할 것이다. 하지만 어떤 Set 구현체를 사용하였느냐에 따라 출력 순서는 달라진다.
java.util.HashSet을 사용하면 출력 결과는 랜덤일 것이다. (JDK8 이후로는 HashSet 순서가 유지되게 구현되는 경우가 많음.)java.util.TreeSet을 사용하면 출력 결과는 정렬될 것이다. (TreeSet은 내부 요소를 정렬한다.)위 예시는 리플렉션의 단점 두 가지를 보여준다.
두 단점 모두 객체를 생성하는 시점에 국한된다. 인스턴스 생성 후에는 생성자로 인스턴스를 생성했건, 리플렉션으로 인스턴스를 생성했건 무관하다.
이 프로그램을 컴파일하면 비검사 형변환 경고가 뜬다. 하지만
Class<? extends Set<String>>으로의 형변환은 먕시한 클래스가 Set을 구현하지 않더라도 성고이할 것이라 문제가 되지는 않는다. 하지만, 해당 클래스의 인스턴스를 생성하는 부분에서ClassCastException을 던질 것이다.🍑 결론
리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드의 의존성을 관리할 때 적합하다. 이 기법은 버전이 여러 개 존재하는 다른 패키지를 다룰 때 유용하다. 가동할 수 있는 최소의 환경 (가장 초기 버전)을 지원하도록 컴파일한 후, 이후 추가된 클래스와 메서드는 리플렉션으로 접근하는 방식이다. 이렇게 하려면 접근하려는 새로운 클래스나 메서드가 런타임에 존재하지 않을 수 있다는 사실을 감안해야 한다.
Referenced by
-