[Effective Java] Item65. 리플렉션보다는 인터페이스를 사용하라!

Item65. 리플렉션보다는 인터페이스를 사용하라!

리플렉션

• 리플렉션 기능(java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다.
• Class 객체가 주어지면 그 클래서의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있다. 이 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다.
• 나아가 가져온 인스턴스를 이용해 각각에 연결된 실체 생성자, 메서드, 필드를 조작할 수도 있다.
• 리플렉션을 이용하면 컴파일 당시에 존재하지 않던 클래스도 이용 가능하다.

리플렉션의 단점

• 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다.
  • 예외 검사도 마찬가지다.
  • 존재하지 않거나 접근할 수 없는 메서드 호출 시도 시 런타임 오류가 발생한다.
• 리플렉션을 이용하면 코드가 지저분하고 장황해진다.
• 성능이 떨어진다.
  • 일반 메서드 호출보다 훨씬 느리다.
• 코드 분석 도구나 의존관계 주입 프레임워크처럼 리플렉션을 써야 하는 복잡한 애플리케이션이 몇 가지 존재하지만, 이런 도구들마저 리플렉션의 사용을 줄이고 있는 추세다. 리플렉션 사용에 확신이 없는 경우라면 그냥 사용하지 말자.

리플렉션을 사용해야 할 때

• 리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점만 취할 수 있다.

  • 컴파일 타임에 이용할 수 없는 클래스를 사용해야만 할 때, 이 클래스에 적절한 인터페이스나 상위 클래스는 컴파일 타임에 사용할 수 있을 것이므로 이를 최대한 활용한다.

  • 리플렉션은 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용하자.

예제

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.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> 인터페이스를 사용하는 예제다.

• 정확한 클래스는 명령줄의 첫 번째 인수로 확정한다. 그리고 생성한 집합에 두 번째 이후의 인수부터 추가한 후 출력한다.

  • 이는 컴파일타임에는 어떤 클래스인지 확인하는 것이 불가능하다는 것을 말한다.

• 인수의 출력 순서는 지정한 클래스가 무엇이냐에 따라 달라진다. HashSet 이라면 무작위 순서가 될 것이고, TreeSet 이라면 알파벳 순서가 될 것이다.

• 이 예제를 통해 리플렉션의 단점 두 가지를 살펴볼 수 있다.

  1. 런타임에 총 여섯 가지나 되는 예외를 던질 수 있다.
     • 리플렉션 없이 생성했다면 컴파일타입에 잡을 수 있는 예외들이다.
  2. 클래스 이름으로만 인스턴스를 생성해내기 위해 무려 25줄이나 되는 코드를 작성했다.
     • 리플렉션을 사용하지 않았다면 생성자 호출 한 줄로 해결됐을 일이다.
  • 두 단점 모두 객체를 생성하는 부분에 국한되는 문제다. 일단 객체 인스턴스를 생성하면, 그 후의 코드는 여타 Set 인스턴스 사용과 동일하다.

리플렉션의 사용

• 드물긴 하지만, 리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할 때 적합하다.
• 버전이 여러 개 존재하는 외부 패키지를 다룰 때 유용하다.
• 접근하려는 새로운 클래스 혹은 메서드가 런타임에 존재하지 않을 수 있다는 사실을 인지하고, 이에 대응하여 같은 목적을 이룰 수 있는 대체 수단의 이용이나 기능을 축소해 동일한 동작을 하도록 하는 조치가 필요하다.

핵심 정리

• 리플렉션은 복잡한 특수 시스템을 개발할 때 강력한 기능이다. 하지만 단점도 많다.
• 컴파일타임에는 알 수 없는 클래스를 사용하는 프로그램을 작성한다면 리플렉션을 사용해야 할 것이다.
• 단, 되도록 객체 생성에만 사용하자. 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에도 알 수 있는 상위 클래스로 형변환하여 사용하자.