item 65 리플렉션보다는 인터페이스를 사용하라

ITEM 65 리플렉션보다는 인터페이스를 사용하라

---

리플렉션을 쓰면 프로그램에서 임의의 클래스에 접근할 수 있다(java.lang.reflect)

• Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있다
• 가져온 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져 올 수도 있다
• Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있다
• 이 인스턴스를 이용해서 해당 클래스의 인스턴스를 생성하거나 메서드를 호출하거나 필드에 접근 가능하다는 말이다
  • ex) Method.invoke는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도 호출할 수 있게 해준다
  • 물론 일반적인 보안 제약사항은 준수해야 한다

리플렉션을 쓰면 컴파일 당시 존재하지 않던 클래스도 이용할 수 있지만 단점도 있다

• 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다
  • 예외 검사도 마찬가지며 프로그램이 리플렉션 기능을 써서 존재하지 않거나 접근할 수 없는 메서드를 호출하려 시도하면 런타임 오류가 발생한다
• 리플렉션을 이용하면 코드가 지저분하고 장황해진다
  • 지루한 일이며 읽기도 어렵다
• 성능이 떨어진다
  • 리플렉션을 통한 메서드 호출은 일반 메서드 호출보다 훨씬 느리다

코드 분석 도구나 의존관계 주입 프레임워크처럼 리플렉션을 써야 하는 복잡한 애플리케이션이 몇가지 있지만 여기서도 리플렉션 사용을 줄이는 추세다

• 명확한 단점 때문이며 개발시 리플렉션이 필요한지 확신할 수 없으면 아마도 필요 없을 가능성이 높다

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

• 컴파일타임에 이용할 수 없는 클래스를 사용해야만 하는 프로그램은 비록 컴파일타임이라도 적절한 인터페이스나 상위 클래스를 이용할 수 있을 것이다
• 이런 경우면 리플렉션은 인스턴스 생성에만 쓰고 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용하자

리플렉션으로 생성하고 인터페이스로 참조해 활용한다

public static void main(String[] args) {
  //클래스 이름을 Class 객체로 변환
  Class<? extends SEt<String>> cl = null;

  try {
    cl = (Class<? extends SEt<String>>) //비검사 형변환
          Class.forName(args[0]);
  } catch (ClassNotFoundExeption 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 구현체를 공격적으로 조작해보며 Set 규약을 잘 지키는지 검사해볼 수 있다
또한 비슷하게 제네릭 집합 성능 분석 도구로 활용할 수도 있다
이 기법은 완벽한 서비스 제공자 프레임워크(item1)를 구현할 수 있을 만큼 강력하며 대부분의 경우 리플렉션 기능은 이정도만 사용해도 충분하다

위 예제는 리플렉션의 단점 두가지를 보여준다

1. 런타임에 총 여섯가지나 되는 예외를 던질 수 있다
   1. 그 모두가 인스턴스를 리플렉션 없이 생성했다면 컴파일타임에 잡아낼 수 있었을 예외다
2. 클래스 이름만으로 인스턴스를 생성해내기 위해 무려 25줄이나 되는 코드를 작성했다
   1. 리플렉션이 아니라 생성자면 한줄이면 끝났을거다

• 두 단점 모두 객체 생성시 발생하는 단점이며 객체 생성이 끝나면 그 이후로는 다른 Set 인스턴스를 사용할 때와 똑같다
  • 따라서 실제 프로그램에서는 이런 제약에 영향받는 코드는 일부에 지나지 않는다

드물긴 하지만 리플렉션은 런타임에 존재하지 않을 수도 있는 다른 클래스, 메서드, 필드와의 의존성을 관리할 때 적합하다

• 이 기법은 버전이 여러개 존재하는 외부 패키지를 다룰 때 유용하다
• 가동할 수 있는 최소한의 환경 주로 가장 오래된 버전만을 지원하도록 컴파일한후 이후 버전의 클래스와 메서드 등은 리플렉션으로 접근한 방법이다
• 이렇게 하려면 접근하려는 새로운 클래스나 메서드가 런타임에 존재하지 않을 수 있다는 사실을 반드시 감안해야 한다
• 즉 같은 목적을 이룰 수 있는 대체 수단을 이용하거나 기능을 줄여 동작하는 등의 적절한 조치를 취해야 한다

리플렉션은 복잡한 특수 시스템을 개발할 때 필요한 강력한 기능이지만 단점도 많다

컴파일 타임에는 알 수 없는 클래스를 사용하는 프로그램을 작성한다면 리플렉션을 사용해야 할 것이다

단 되도록 객체 생성에만 사용하고 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환해 사용해야 한다