[자바] 널(null)이 아닌 제로 길이(zero-length) 배열 반환

다음과 같은 메소드는 흔히 볼 수 있습니다.

private List cheesesInStock = ...;

/**
 *     @상점에서 치즈의 모든 것을 포함하는 배열을 반환하거나
 *     구매 가능한 치즈가 없다면 널(null)이다.
 */
public Cheese[] getCheeses() {
	if(cheeseInStock.size() == 0)
		return null;
}

치즈를 구매할 수 없는 상화에 특별한 경우를 만들 이유가 없습니다. 이렇게 할 경우 null 반환 값을 처리하기 위해 클라이언트에 코드를 추가로 작성해야 합니다. 다음 예제를 보겠습니다.

Cheese[] cheeses = shop.getCheeses();
if (cheeses != null && Arrays.asList(shop.getCheeses()).contains(Cheese.STILTON))
	System.out.println("Jolly good, just the thing.");

대신

if (Array.asList(shop.getCheeses()).contains(Cheese.STILTON))
	System.out.println("Jolly good, just the thing.");

제로 길이 배열(zero length array) 대신 null을 반환하는 메소드를 사용할 때마다 거의 매번 이러한 완곡어법(circumlocution)을 사용해야 합니다. 클라이언트를 작성하는 프로그래머가 널 문자를 처리하는 특별한 코드를 작성하는 것을 잊어버릴 수 있기 때문에 오류가 잘 발생합니다. 이러한 메소드는 대개 하나 이상의 객체를 반환하기 때문에 위와 같은 오류는 수 년간 발견되지 않을 수도 있습니다. 제로 길이 배열 대신에 null을 반환하는 것은 배열 반환 메소드 자체를 복잡하게 만들 수 있다는 점도 중요성은 좀 떨어지지만 여전히 알아야 할 사항입니다.

null 반환 값은 배열 할당 비용을 막을 수 있기 때문에 null 반환 값이 제로 길이 배열보다 더 낫다고 주장하는 경우도 가끔 있습니다. 이러한 주장은 두 가지 측면에서 잘못된 것입니다. 첫째, 프로필 작업에서 문제의 메소드가 성능 문제의 실제 원인이라는 것이 입증되지 않는 한 지금 레벨에서 성능을 우려하는 것은 옳지 못합니다. 둘째, 제로 길이 배열은 수정이 불가능하며 immutable 객체는 자유롭게 공유할 수 있기 때문에 항목을 반환하지 않는 호출로부터 매번 동일한 제로 길이 배열을 반환할 수 있습니다.

사실상, 프로그래머가 컬렉션에서 타입화된 배열(typed array)로 항목을 이동(dump)하기 위해 표준 이디엄을 사용할 때 동일한 상황이 발생합니다.

private List cheesesInStock = ...;

private final static Cheese[] NULL_CHEESE_ARRAY = new Cheese[0];

/**
 *  @상점에서 치즈의 모든 것을 포함하는 배열을 반환한다.
 */
public Cheese[] getCheeses() {
	return (Cheese[]) cheeseInStock.toArray(NULL_CHEESE_ARRAY);
}

이 이디엄에서 제로 길이 배열 상수는 바람직한 반환 타입을 표시하기 위해 toArray 메소드로 전송됩니다. 일반적으로 toArray 메소드는 반환된 배열을 할당합니다. 그러나 컬렉션이 비어있다면 입지하기에 충분한 크기라면 입력 배열이 반환된다는 것을 보장해줍니다. 따라서, 이 이디엄은 제로 길이 배열을 할당하는 대신 "타입 지정자 상수(type-specifier constant)"를 재사용합니다.

요약하자면, 제로 길이 배열을 반환하는 대신에 배열 값 메소드(array-valued method)에서 null을 반환할 이유가 없습니다. 이 이디엄은 C 프로그래밍 언어에서 잔류한 것 같습니다. C 프로그래밍 언어에서 배열 길이는 실제 배열과는 별도로 반환됩니다. C에서 제로(0)가 길이로 반환된다면 배열 할당의 장점이 장점이 사라지게 됩니다.