[Item65] 리플렉션 못 본 척 하기

Item65에서는 리플렉션보다는 인터페이스를 사용하라 말한다

이유는 간단하다

메서드를 직접 호출하면 컴파일된 코드를 실행하는데 반해 리플렉션은 bytecode에서 metadata를 찾아야 하기 때문이다

 

https://softwareengineering.stackexchange.com/questions/123956/why-should-i-use-reflection#:~:text=Reflection%20is%20much%20slower%20than%20just%20calling%20methods%20by%20their%20name%2C%20because%20it%20has%20to%20inspect%20the%20metadata%20in%20the%20bytecode%20instead%20of%20just%20using%20precompiled%20addresses%20and%20constants.

 

책에서는 리플렉션을 사용할 때의 단점을 나열하는데 다음과 같다

1. 컴파일 타입 검사 불가

2. 장황한 코드

3. 성능 저하

 

단점들을 보니 리플렉션을 쓰지 말아야 할 이유만 생기는 것 같다

컴파일 타입 검사 불가는 정적 타입 언어를 사용하는 이유를 무색하게 하고

장황한 코드는 안 그래도 지저분한 자바를 더 지저분하게 만들며

C, C++에 비해 구린 성능의 자바를 더욱 구리게 만든다

 

위 사진에 달린 링크를 따라가 보면 현실에서 리플렉션이 유용한 단 하나의 이유는 프레임워크에서의 사용이라 한다

즉 자신이 만들고 관리할 프로젝트에서는 리플렉션을 사용할 이유가 없고

오직 다른 이에게 제공할 목적으로 만드는 프로젝트에서만 의미가 있다

작성 중인 프로젝트에서 직접 제어할 수 없는 클래스를 간접적으로 제어하기 위해 metadata를 이용해 강제로 제어한다

그렇기에 접근 제한자도 무시해버릴 수 있고 리플렉션 방어를 하지 않은 싱글턴을 깨버릴 수도 있게 되는 것이다

 

스프링과 같은 DI Framework 혹은 Fortify & SonarCube 같은 코드 분석 도구에서 유용하다고 한다

이를 찾아보기 전에는 진행 중인 사이드 프로젝트에 리플렉션을 이용해 다형적인 메서드 콜을 써볼까 했었다

사실 요즘의 H/W 성능에서 리플렉션에 의한 성능 저하는 리플렉션 떡칠을 해두지 않았다면 거의 영향 없을 것이고

컴파일 타입 검사와 장황한 코드는 오직 내가 유지 보수할 테니 문제없었을 것이다

리플렉션을 사용하기 전에 Item65를 다시 한번 읽었고 사용할 이유가 학습 외에 없기 때문에 쓰지 않기로 했다

 

백기선님의 자바 바이트 코드 조작 강의를 봤었을 때

많은 라이브러리들이 성능 문제로 Reflection 대신 CGLib 기반으로 옮겨간다고 들었다

도구 탓하지 않을 자바 장인들도 리플렉션을 사용 안 하는데 햇병아리도 당연 따라가야 한다

최근 회사 복지로 자바 웹 프로그래밍 넥스트 스텝이란 책을 샀다

책에 HTTP Web Server, DI Framework를 만드는 과정이 있는데 그 때나 한번 써봐야겠다