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

[coalong]

아이템 설명

리플렉션에 대해 알아보고 리플렉션을 사용할 때 단점과 주의점을 설명한다.

리플렉션 이란?

• 리플렉션(Reflection) 은 런타임 시점에 동적으로 동작하는 것.
• 컴파일 시점에 구체적인 클래스 타입을 알지 못해도 그 클래스의 메소드, 필드, 생성자에 접근할 수 있다.

리플렉션은 어떻게 동작할까?

• 리플렉션은 Class 클래스 API 를 사용하여 동작한다.
• 모든 클래스는 자바 컴파일러에 의해 Class 객체로 만들어지고, 리플렉션은 Class 객체를 이용하여 클래스의 정보를 알 수 있다.

1. 클래스 얻기
Class<?> class = Class.forName();

2. 생성자 얻기
Constructor<?> constructor = class.getDeclaredConstructor();

3. 클래스 인스턴스 만들기
constructor.newInstance();

리플렉션 사용

• 리플렉션을 사용해서 클래스의 메소드, 필드, 생성자 인스턴스를 가져오고
  그 인스턴스의 실제 생성자를 통해 인스턴스를 생성하거나 메서드를 호출, 필드에 접근할 수 있다.

리플렉션 사용시 단점

• 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다.
  → 컴파일 시점에 확인할 수 있는 에러를 런타임 단계에서 확인하게 된다.
• 리플렉션을 이용하면 코드가 장황해지고 가독성도 떨어진다.
• 캡슐화 저해
  → Reflection 은 private 한 필드, 메서드에 접근 가능하기 때문에 캡슐화가 깨지게 된다.
• 성능 저하가 생길 수 있다.
  → 리플렉션을 사용하면 컴파일러가 최적화하기 어렵고, 일반 메서드 호출보다 훨씬 느리다.

리플렉션 언제 사용할까 ?

• 우리가 많이 사용하는 프레임워크나 라이브러리 등 복잡한 애플리케이션에서 리플렉션을 쓰고 있다.

예시

• IDE 의 자동완성 기능
• Spring framework:
  • Dependency Injection
  • MVC 의 View에서 넘어오는 데이터를 객체에 바인딩할 때 사용
• Hibernate: @entity 클래스에 setter가 없으면 해당 필드에 값을 바로 주입
• Jackson
• JUnit: ReflectionUtils 클래스를 내부적으로 정의하여 사용

⭐️ 리플렉션 사용시 주의점 (이번 아이템 주 내용)

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

• 컴파일 타임에 알 수 없는 클래스를 사용해야만 할 때 비록 컴파일 타임이라도 적절한 인터페이스나 상위 클래스를 이용 할 수 있을 것이다.
  아이템 64. 객체는 인터페이스를 사용해 참조하라
• 즉, 리플렉션은 인스턴스 생성에만 쓰고, 만든 인스턴스는 인터페이스나 상위클래스로 참조해 사용하자!

예시

• 리플렉션으로 생성하고 Set<String> 인터페이스를 참조한 예시 코드
• args를 통해 첫 번째 인수로 지정한 클래스가 무엇이냐에 따라 실행 결과가 달라진다.
  • 즉, 컴파일타임에는 어떤 클래스인지 알 수 없다.
• HashSet을 지정하면 무작위 순서가 될 것이고, TreeSet을 지정하면 알파벳 순서가 될 것이다.

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);
}

• 이 예시는 리플렉션의 단점 두 가지를 보여준다.
  • 리플렉션 없이 생성했다면 컴파일 시점에 알 수 있었던 예외(6개)를 런타임 시에 잡을 수 있게 됐다.
  • 리플렉션 없이 생성한다면 생성자 호출 1줄로 가능 한 것을 클래스 이름만으로 인스턴스를 생성하기 위해 25줄이나 되는 코드를 작성했다.
• 그래도 두 단점 모두 객체를 생성하는 부분에만 국한된다.
  • 객체가 일단 만들어지면 그 후의 코드는 기존의 인스턴스를 사용할 때와 똑같다.

핵심정리

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

참고자료

https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/reflect/package-summary.html
https://junit.org/junit5/docs/5.0.3/api/org/junit/platform/commons/util/ReflectionUtils.html#method.detail
https://catsbi.oopy.io/b78957f6-d26e-404f-a05e-2396a2609183
https://dublin-java.tistory.com/53

[corock]

쉽지 않은 내용일 수 있는데 잘 정리하셨네요~ 잘 봤습니다.
저는 처음에 리플렉션을 극혐하는 입장이었는데, 웹 개발에서 단위 테스트를 작성할 때 ReflectionTestUtils 는 앞으로 적극적으로 사용하려고 합니다.
해당 클래스를 사용하면 Setter 사용을 막을 수 있거든요. 이와 반대로 ReflectionUtils 클래스는 아직 혐오하긴 합니다 :)