자바 8 이전
기존 구현체(인터페이스를 직접 구현한 클래스)를 깨뜨리지 않고 인터페이스에 메서드를 추가할 방법이 없었음.
인터페이스에 메서드를 추가하면 보통은 컴파일 오류가 나는데, 추가된 메서드가 우연히 기존 구현체에 이미 존재할 가능성이 아주 낮기 때문.
자바 8 이후
기존 인터페이스에 메서드를 추가할 수 있도록 디폴트 메서드를 소개했지만 [JLS 9.4], 위험이 완전히 사라진 것은 아니다.
- 인터페이스는 메서드에 대한 선언만 가능하기 때문에, 실제 로직은 포함될 수 없다.
- 하지만 메소드 선언시 default를 명시하게 되면 인터페이스 내부에서도 동작 코드가 포함된 메서드를 선언 할 수 있다.
- default 키워드는 인터페이스에 메서드를 추가함과 동시에 하위호환성을 유지할 수 있도록 해주는 큰 편의를 제공해준다.
(출처)
디폴트 메서드 선언 시 그 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.
하지만 모든 기존 구현체들과 연동된다는 보장은 없다. 왜냐하면 디폴트 메서드는 구현 클래스에 대해 아무것도 모르기 때문이다.
자바 8에서는 핵심 컬렉션 인터페이스에 다수의 디폴트 메서드가 추가되었다. 람다를 활용하기 위해서이기 때문이다.
하지만 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어려운 법.
예시) 자바 8의 Collection 인터페이스에 추가된 removeIf 메서드
removeIf : 주어진 불리언 함수(predicate)가 true를 반환하는 모든 원소를 제거.
디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 프레디키트 호출, 프레디키트가 true를 반환하려면 반복자의 remove 메서드를 호출해 그 원소 제거.
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 구현체와 잘 어우러지는 것은 아님.
org.apache.commons.collections4.collection.SynchronizedCollection
- java.util의 Collections.synchronizedCollections 정적 패터리 메서드가 반환하는 클래스와 비슷.
- 아파치 버전은 컬렉션 대신 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공.
- 즉, 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스
- 하지만, 현 시점에선 removeIf 메서드를 재정의하고 있지 않으므로 이 클래스를 자바 8과 함께 사용할 땐 모든 메서드 호출을 알아서 동기화해주지 못 함.
- removeIf의 구현은 동기화에 관해 아무것도 모르므로 락 객체 사용 불가.
- SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removeIf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어진다.
위 문제를 해결하기 위한 조치
- 구현한 인터페이스의 디폴트 메서드 재정의, 다른 메서드에선 디폴트 메서드를 호출하기 전 필요한 작업 수행
- Collections.synchronizedCollection이 반환하는 package-private 클래스들은 removeIf 재정의, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화하도록 함.
- 하지만 자바 플랫폼에 속하지 않은 제3의 기존 컬렉션 구현체들은 이런 언어 차원이 인터페이스 변화에 발맞춰 수정될 기회가 없었으며, 그 중 일부는 여전히 수정되고 있지 않음.
디폴트 메서드는 (컴파일에 성공하더라도) 기존 구현체에 런타입 오류를 일으킬 수 있다.
자바 8은 컬렉션 인터페이스에 꽤 많은 디폴트 메서드를 추가했고, 그 결과 기존에 짜여진 많은 자바 코드가 영향을 받은 것으로 알려졌다.
기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일을 꼭 필요한 경우가 아니라면 피해야 한다.
- 추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지 않을 지 심사숙고해야한다.
- 반면, 새로운 인터페이스를 만드는 경우라면 표준적인 메서드 구현을 제공하는데 아주 유용하며, 그 인터페이스를 더 쉽게 구현해 활용할 수 있게 해준다(아이템 20).
디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명심
이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨림.
'디폴트 메서드'라는 도구가 생겼더라도 인터페이스를 설계할 땐 여전히 주의!
- 디폴트 메서드로 기존 인터페이스에 새로운 추가하면 커다란 위험도 딸려온다.
- 심히 잘못된 인터페이스라면 이를 포함한 API에 큰 문제가 생길 수 있음.
대안
- 새로운 인터페이스라면 릴리스 전에 반드시 테스트하기
- 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들기
결론
인터페이스를 릴리스한 후 결함 수정이 가능은 하겠지만, 절대로 그 가능성에 기대지 말라.
