디폴트 메소드의 위험성

자바 8 전에는 기존 구현체를 변경하지 않고는 인터페이스에 메소드를 추가할 수 없었다. 자바8에 와서 기존 인터페이스에 메소드를 추가할 수 있도록 디폴트 메소드를 소개했지만 위험이 완전히 사라진 것은 아니다. 디폴트 메소드는 구현 클래스에 대해 아무것도 모른채 합의 없이 무작정 삽입될 뿐이다.

자바 8에서는 핵심 컬렉션 인터페이스들에 다수의 디폴트 메소드가 추가되었다. 주로 람다를 활용하기 위해서다. 자바 라이브러리의 디폴트 메소드는 코드 품질이 높고 범용적이라 대부분 상황에서 잘 동작한다. 하지만 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메소드를 작성하기는 어려운 법이다.

자바 8의 Collection 인터페이스에 추가된 removeIf 메소드를 보자. 이 메소드는 주어진 boolean 함수가 true를 반환하는 모든 원소를 제거한다.

default boolean removeIf(Predicate<? super E> filter) {
	Objects.requireNonNull(filter);
	boolean removed = false;
	final Iterator<E> each = iterator();
	while (each.hasNext()) {
		if (filter.test(each.next())) {
			each.remove();
			removed = true;
		}
	}
	return removed;
}

이 코드보다 범용적으로 구현하기도 어렵겠지만 그렇다고 현존하는 모든 Collection 구현체와 잘 어우러지는 것도 아니다. 대표적인 예가 apache commons의 SynchornizedCollection이다.

아파치 커먼즈 라이브러리의 이 클래스는 java.util의 Collections.synchronizedCollection 정적 팩터리 메소드가 반환하는 클래스와 비슷하다. 즉, 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공한다. 다시말해 모든 메소드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스이다.

하지만 removeIf가 나온 시점에는 아파치 커먼즈 라이브러리에서 removeIf가 재정의되어 있지 않다. removeIf는 동기화에 대해 아무것도 모르므로 락 객체를 사용할 수 없다. 따라서 멀티 스레드 환경에서 한 스레드가 removeIf를 호출한다면 결과를 보장할 수 없게 된다.

자바 플랫폼 라이브러리에서도 이런 문제를 예방하기 위해 인터페이스의 디폴트 메소드를 재정의하고 다른 메소드에서는 디폴트 메소드를 호출하기 전에 필요한 작업을 수행하도록 했다. 하지만 자바 플랫폼에 속하지 않은 써드파티 컬렉션 구현체들은 이런 언어차원의 인터페이스 변화에 발맞춰 수정될 기회가 없었고 일부는 아직도 수정이 되지 않고 있다.

디폴트 메소드는 기존 구현체에 런타임 오류를 일으킬 수 있다. 흔하지는 않지만 충분히 일어날 수 있는 일이다. 그렇기 때문에 기존의 인터페이스에 디폴트 메소드를 추가하는 일은 꼭 필요한 경우가 아니라면 피해야한다. 추가를 해야 한다면 충분한 심사숙고와 검토가 이루어져야 한다. 반면 새로운 인터페이스를 만드는 경우라면 표준적인 메소드 구현을 제공하는데 아주 유용한 수단이며 그 인터페이스를 더 쉽게 구현해 활용할 수 있게끔 도와준다.

디폴트 메소드는 인터페이스로부터 메소드를 제거하거나 기존 메소드의 시그니처를 수정하는 용도가 아니다. 이런 형태로 사용하면 기존 클라이언트를 망가트리게 된다. 핵심은 명백하다. 디폴트 메소드가 있더라도 인터페이스를 설계 할 때는 여전히 세심한 주의를 기울여야 한다.