- 자바 8전에는 기존 구현체를 깨드리지 않고는 인터페이스에 메서들르 추가할 방법이 없었다.
- 자바 8에 와서 기존 인터페이스에 메서드를 추가할 수 있도록 디폴트 메서드를 소개했지만 위험이 완전히 사라진 것은 아니다.
- 모든 기존 구현체들과 매끄럽게 연동되리라는 보장이 없다.
- 디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 삽입될 뿐이다.
- 자바 8의 Collection 인터페이스에 추가된 removeIf 메서드를 예로 생각해보자.
- 이 메서드는 주어진 Predicate 가 true를 리턴하는 모든 원소를 제거한다. 디폴트 구현은 이터레이터로 순회하면서 각 원소를 인수로 넣어 Predicate를 호출하고 true를 리턴하면 반복자의 remove 메서드를 호출해 그 원소를 제거한다.
1
2
3
4
5
6
7
8
9
10
11
12
// 코드 21-1 자바8의 Collection 인터페이스에 추가된 디폴트 메서드
default boolean removeIf(Predicate<? super E> filter) {
Objects.requireNonNull(filter);
boolean result = false;
for (Iterator<E> it = iterator(); it.hasNext(); ) {
if (filter.test(it.next())) {
it.remove();
result = true;
}
}
return result;
}
- 위 코드는 현존하는 모든 Collection 구현체와 잘 어우러지는 것은 아니다.
- 대표적인 예로
아파치 커먼저 라이브러리에서 제공하는 SynchronizedCollection이다.- 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스이다.
- 이 클래스를 자바8과 함께 사용한다면(removeIf의 디폴트 구현을 물려받게 된다면), 자신이 한 약속을 더 이상 지키지 못하게 된다. 다시 말해 모든 메서드 호출을 알아서 동기화해주지 못한다. removeIf의 구현은 동기화에 관해 아무것도 모르므로 랄 객체를 사용할 수 없다.
자바 플랫폼 라이브러리에서도 이런 문제를 예방하기 위해 일련의 조치를 취했다.
- 예를 들어 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다.
- 예컨대, Collections.synchronizedCollection이 반환하는 package-private 클래스들은 removeIf를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 했다.
디폴트 메서드는 (컴파일에 성공하더라도) 기존 구현체에 런타임 오류를 일으킬 수 있다.
- 흔한 일은 아니지만, 가능성을 무시해선 안된다.
기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니라면 피해야 한다.
- 추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지 않을지 심사숙고해야 함도 당연하다.
한편 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명심해야 한다.
- 이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 된다.