[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자.

[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자.

-
리플렉션은 여러모로 강력한 기능을 제공한다.
하지만 이런 강력함은 다음의 대가들을 수반한다.

컴파일 시점에 가능한 타입 확인의 장점이 없어진다.
재귀적인 접근을 필요로 하는 코드는 알아 보기 어렵고 길다.
처리 성능이 늦다.


-
사실 리플렉션은 컴포넌트 기반의 어플리케이션 개발 도구용으로 설계되었다.
따라서 일반적으로 런타임에서는 리플렉션을 이용해서 재귀적으로 사용하면 안된다.


-
리플렉션이 필요한 복잡한 애플리케이션은 다음과 같다.
    클래스 브라우저
    객체 조사기
    코드 분석 도구
    RPC


-
리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다.
예를 들어 컴파일 시점에는 쓸 수 없는 클래스를 사용해야 하는 프로그램의 경우가 그렇다.
단 이 때 그 클래스의 인스턴스를 재귀적으로 생성한 후, 그것의 인터페이스나 수퍼 클래스를 통해서 그 인스턴스를 보통 때처럼 사용하는 것이 좋다.

ex)

public static void main(String[] args){

Class<?> cl = Class.forName(args[0]);

Set<String> s = null;

try{

s = (Set<String>) cl.newInstance();

} catch( Exception e ){

// do sth..

}

// do sth...

}

-
위와 같이 사용하는 것이 재귀적으로 리플렉션을 사용하는 것보다 훨씬 유용하지만,
그렇다 해도 2가지 큰 단점을 볼 수 있다.

    런타임 에러를 발생시킬 수 있다.
    쓸데없이 긴 코드가 발생한다

단 객체를 생성하지 않는 코드는 이런 단점을 가지지 않을 수 있으나, reflection 은 컴파일 에러로 검출이 되지 않아 일단 위험하다.


-
리플렉션을 잘 사용하는 경우는 런타임 시에 없을 수 있는 클래스, 메소드, 필드에 대한 특정 클래스의 의존도를 관리하는 것이다.
예를 들어 여러 버전으로 된 어떤 다른 패키지에 맞추어 실행되어야 하는 그런 패키지를 작성할 때 유용하다.
지원에 필요한 최소 환경(오래된 버전)에 맞추어 컴파일 하고, 새로운 버전의 클래스나 매소드는 리플렉션을 이용하여 사용하게 하는 것이다.
( 버전 점유율에 따라 그 반대로 )

Summary

리플렉션은 강력한 관리 시스템이며, 특정의 복잡한 시스템 프로그래밍에 필요하다.
그러나 단점도 많이 있다.
컴파일 시점에 알 수 없는 클래스들과 함께 동작해야 하는 프로그램을 작성한다면, 객체를 생성할 때만 리플렉션을 사용해야 한다.
그리고 그 객체를 사용할 때는 컴파일 시점에 알 수 있는 인터페이스나 수퍼 클래스를 이용해야 한다.

effecitv ejava, Reflection, RPC, runtime error, runtime exception, [Effecitve Java] 리플렉션보다는 인터페이스를 사용하자., 개발 도구용, 객체 조사기, 관리 시스템, 긴 코드, 단점, 대가, 런타임, 런타임 에러, 리플렉션, 메소드, 생성, 수퍼 클래스, 시스템 프로그래밍, 앱, 의존도, 인스턴스, 인터페이스, 장점, 재귀, 재귀적인 접근, 처리 성능, 컴파일, 컴포넌트 기반 앱 개발, 코드 분석 도구, 클래스, 클래스 브라우저, 타입 확인, 필드