<Effective Java> RULE 53 리플렉션 대신 인터페이스를 이용하라

 

java.lang.reflect의 핵심 리플렉션기능을 이용하면 메모리에 적제된 클래스의 정보를 가져오는 프로그램을 작성할 수 있다.

· Class에서 생성자, 메서드, 필드객체

· 클래스의 멤버 이름, 필드 자료형, 메서드 시그니쳐 정보

 

단점

· 컴파일 시점에 자료형을 검사함으로써 얻는 장점을 포기

· 장황한 코드가 된다, 가독성이 떨어진다.

· 성능이 낮다. 일반적인 메서드 호출에 비해 훨씬 낮다. 2배~50배 차이

 

 

원래 리플렉션 기능은 컴포넌트 기반 응용프로그램 저작 도구를 위해 설계된 기능

· 클래스를 메모리에 올린 다음, 리플렉션 기능을 통해 어떤 메서드와 생성자가 지원되는지 알아내며 응용프로그램과 대화형으로 만들어 나갈 수 있다. 하지만 완성된 프로그램은 리플렉션을 더 이상 사용하지 않는다.

· 리플렉션은 설계할 때만 활용된다.

 

일반적인 프로그램은 프로그램 실행 중 리플렉션을 통해 객체를 이용하려 한다면 안된다.

 

리플렉션은 언제 필요한가?

· 클래스 브라우저

· 객체 검사 도구

· 코드 분석 도구

· 해석적 내장형 시스템(interpretive embedded system)

 

리플렉션을 아주 제한적으로만 사용하면 오버헤드는 피라면서 리플렉션의 다양한 장점을 누릴 수 있다.

객체 생성은 리플렉션으로 하고 객체 참조는 인터페이스나 상위 클래스를 하면 된다.

public class Rule53 {
    public static void main(String[] args) {
        // 클래스 이름을 Class객체로 변환
        Class<?> cl = null;
        try {    
            cl = Class.forName(args[0]);
        }catch (ClassNotFoundException e) {
            System.err.println("Class not found");
            System.exit(1);
        }
        
        // 해당 클래스의 객체 생성
        Set<String> s = null;
        try {
            s = (Set<String>) cl.newInstance();
        }catch (IllegalAccessException e) {
            System.err.println("Class not accessible.");
            System.exit(1);
        } catch (InstantiationException e) {
            System.err.println("Class not instantiable.");
            System.exit(1);
        }
        
        // 집합 이용
        s.addAll(Arrays.asList(args).subList(1,args.length));
        System.out.println(s);
    }
}

 

하나 이상의 객체를 조작하여 해당 구현이 Set의 일반 규약을 준수하는지 검증하는 일반적인 집합 검사도구가 될 수 있다.

 

위의 예제의 단점

· 세가지 실행 시점 오류를 발생시킨다.

ㄴ 컴파일 시점에 오류를 검사할 수 있는 부분이지만 리플렉션으로 객체를 생성하여 생긴 부분.

ㄴ 이름에 대응하는 클래스의 객체를 생성하기 위해 스무 줄 가량의 멍청한 코드를 사용하게 된다.

ㄴ생성자였다면 한줄로 되었다.

 

결론

· 리플렉션은 특정한 종류의 복잡한 시스템 프로그래밍에 필요한, 강력한 도구

· 단점이 많다.

· 컴파일 시점에는 알 수 없는 클래스를 이용하는 프로그램을 작성한다면 리플렉션은 객체를 만들 때만 사용하고 객체를 참조하는것은 컴파일 시 알고 있는 인터페이스나 상위 클래스를 이용하라.