컬렉션이 비었을 경우 null로 반환하면 될까?
런타임에 NullPointerException 예방하기 위해 클라이언트는 null 상황을 처리하는 코드를 추가로 작성해야한다.
컬렉션이나 배열같은 컨테이너가 비었을 때 null을 반환하는 메서드를 사용할 때면 항상 이와같은 방어 코드를 넣어줘야 한다.
때로는 빈 컨테이너를 할당하는데도 비용이 드니 null을 반환하는 쪽이 낫다는 주장도 있지만 이는 두가지 면에서 틀린 주장이다.
- 성능분석 결과 이 할당이 성능 저하의 주범이라고 확인되지 않는 한, 이 정도의 성능 차이는 신경 쓸 수준이 못 된다.
- 빈 컬렉션과 배열은 굳이 새로 할당하지 않고도 반환할 수 있다.
가능성은 작지만 사용 패턴에 따라 빈 컬렉션 할당이 성능을 눈에 띄게 떨어뜨릴 수 있다.
해법은 매번 똑같은 불변 컬렉션을 반환하는 것이다. 불변 객체는 자유롭게 공유해도 안전하다.
단, 이 역시 최적화에 해당하니 꼭 필요할 때만 사용하자. 최적화가 필요하다고 판단되면 수정 전과 후의 성능을 측정하여 실제로 성능이 개선되는지 꼭 확인하자.
배열을 쓸 때도 마찬가지로 절대 null을 반환하지 말고 길이가 0인 배열을 반환하라
다음 코드에서 toArray 메서드에 건넨 길이 0짜리 배열은 우리가 원하는 반환타입을 알려주는 역할을 한다.
이 방식이 성능을 떨어뜨릴 것 같다면 길이 0짜리 배열을 미리 선언해두고 매번 그 배열을 반환하면 된다. 길이 0인 배열은 모두 불변이기 때문
이 최적화 버전의 getCheeses는 항상 EMPTY_CHEESE_ARRAY를 인수로 넘겨 toArray를 호출한다. 따라서 cheesesInStock이 비었을 때면 언제나 EMPTY_CHEESE_ARRAY를 반환한다.
단순히 성능을 개선할 목적이라면 toArray에 넘기는 배열을 미리 할당하는건 성능이 떨어진다는 연구결과도 있어 추천하지 않는다.
핵심정리
null이 아닌, 빈 배열이나 컬렉션을 반환하라. null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은 것도 아니다.
'개인룸 > 도윤' 카테고리의 다른 글
Item56. 공개된 API 요소에는 항상 문서화 주석을 작성하라 (0) | 2023.07.22 |
---|---|
Item55. 옵셔널 반환은 신중히 하라 (0) | 2023.07.21 |
Item53. 가변인수는 신중히 사용하라 (0) | 2023.07.19 |
Item52. 다중정의는 신중히 사용하라 (0) | 2023.07.19 |
Item51. 메서드 시그니처를 신중히 설계하라 (0) | 2023.07.13 |