[Item27] @SuppressWarnings 알고 쓰자

이전 아이템에서 Generics를 꼭 써야 한다는 것을 배웠다

다만 어떤 기술이든, 어떤 언어든 무언가를 도입함에 따라 장단점이 따라오게 되어있다

새로운 기술은 도입할 때의 장단점을 저울질해 이전의 장단점들을 상쇄하고 남을 효용이 생기면 도입해야 한다

 

Generics 장점으로 type-safety를 지켜주어 번거로운 형 변환이 필요 없고 잘못된 값이 들어갈 일이 없다는 점이 있다

단점으로 수 많은 unchecked-call이 뜰 수 있다는 것인데 잘 생각해보면 이건 장점이다

사용자 입장에서 타입 체크를 제대로 안 했기 때문에 친절한 IDE가 컴파일 전에 미리 뿜어내 주는 것이다

IDE에서 문법 오류나 구식 for문을 향상된 for문으로 바꿔주는 것과 같은 자동 수정은 지원하지 않으나

비검사 경고가 뜬다는 것만으로도 감사할 일이다

대부분이 개발자가 Generics를 잘못 사용해 나오는 것이니 빠르게 해결해주자

 

한 가지 예외가 있다면 사용자가 의도해 <Object> 형태를 쓸 때인데

나의 경우 최근 진행하는 프로젝트에서 Sort 객체를 만들 때 데이터 타입에 따라

OrderSpecifier<String>, OrderSpecifier<Integer>, OrderSpecifier<LocalDateTime> 를 만드는 건 너무 번거롭고

만들어진 Sort를 내가 다시 꺼내 쓰는 것이 아닌, QueryDSL에 파라미터로 넘기기 위한 것이므로

간단하게 OrderSpecifier<Object>로 받아버리게 코드 작성 후 @SuppressWarnings를 때려주었다

@SuppressWarnings({"rawtypes", "unchecked"})

 

@SuppressWarnings를 처음 봤을 때는 타입을 잘 지정해서 처리해야 할 경고를 왜 숨길까라는 순진한 생각을 했다

이 애노테이션 역시 존재 의의가 확실한데 비검사 경고도 컴파일 시 터트리진 않지만 경고를 띄우기 때문에

경고 로그가 찍히는데 이 로그 때문에 다른 진짜 문제가 가려질 수 있기 때문에 사용한다고 한다

개발자가 의도한 코드로 type-safety가 깨지기는 했지만 문제 없는 경우에 붙여줘야 한다

주의할 점은 rawtypes를 쓰고 unchecked call이 떴지만 의도적으로 로그를 가리는 거라 가능한 좁은 범위에 사용해야 한다

핵심 메서드에 쟤를 붙이는 건 지양하고 비검사 경고가 뜨는 부분을 분리해 작은 메서드로 만들고 애노테이션을 붙여주자

 

만약 내가 작성한 코드에서 비검사 경고를 처리하려면 앞서 말했듯 데이터 타입 별로 OrderSpecifier를 만들어야 하고

매번 데이터 타입 체크 후 타입에 맞는 OrderSpecifier에 넣은 후 다시 Sort에 넣어야 한다

난 재사용성을 높이기 위해 최대한 범용적으로 만들었고 그에 따라 Object 형태로 받는 걸 선택했다

아직 Generics에 능숙하지 못 해서일 수도 있고, 이 방법이 최선일 수도 있다

더 나은 방법을 알게 된다면 업데이트 해야겠다