Item21 : 인터페이스는 구현하는 쪽을 생각해 설계하라

현재 자바 8 이전 버전에서는 기존 구현체를 깨트리지 않고는 인터페이스에 메서드를 추가할 방법이 없었다. 그래서 자바 8 이후에 디폴트 메서드를 통해 기존 인터페이스에 추가할 수 있도록 했다.

디폴트 메소드가 추가되면서 자바에서도 기존 인터페이스에 메서드를 추가하는 방법이 생겼지만 기존 구현체와 매끄럽게 연동이 되긴 힘들다. 그 이유는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 삽입시킬 수 있기 때문이다.

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

 

예를 들어 Collection의 removeIf() 를 보자

• Collection의 removeIf() 메소드

default boolean removeIf(Predicate<? super E> filter) {
    Objects.requireNonNull(filter);
    boolean result = false;
    for (Iterator<E> it = iterator(); it.hashNext(); ) {
        if (filter.test(it.next())) {
            it.remote();
            result = true;
        }
    }
    return result;
}

이 메서드는 주어진 불리언 함수가 true를 반환하는 모든 원소를 제거한다. 디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 프레디케이트를 호출하고, 프레디케이트가 true를 반환하면 반복자의 remove 메서드를 호출해 그 원소를 제거한다.

하지만 이 코드는 Collection 구현체와 잘 어울려지지 않는다. 대표적인 예가 Apache commons의 SynchronizedCollection이다. 해당 클래스는 모든 메서드에서 클라이언트가 준 락 객체로 동기화 후 내부 컬렉션 객체에 기능을 위임하는 기능을 가지고 있는데, removeIf() 메서드를 재정의하지 않고 있다.

즉 자바8과 함께 사용한다면 removeIf()의 구현은 동기화에 관해 아무것도 모르므로 락 객체를 사용할 수 없게 된다. 다시 말해 모든 메서드 호출을 알아서 동기화해 주지 못한다. 따라서 만약 removeIf를 호출하면 인스턴스를 여러 스레드가 공유하는 환경에서는 ConcurrentModificationException이 발생하거나 다른 예기치 못한 상황이 발생할 수 있다.

 

정리

자바 플랫폼 라이브러리에서도 이런 문제를 예방하기 위해 일련의 조치를 취했다. 예를 들어 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메소드에서는 디폴트 메소드를 호출하기 전에 필요한 작업을 수행하도록 시켰다. 하지만 자바 플랫폼에 속하지 않은 제3의 기존 컬렉션 구현체들은 이런 방식으로 수정되지 않는 경우가 있어 조심해야 한다.

정리하자면 디폴트 메서드는 기존 구현체에 런타임 오류를 일으킬 수 있다. 그렇기 때문에 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니라면 피해야 한다. 또한 추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지는 않을지 심사숙고해야 한다. 그리고 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명시해야 한다.

마지막으로 디폴트 메서드가 아무리 편하더라도 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야 한다. 디폴트 메서드로 기존 인터페이스에 새로운 메서드를 추가하면 커다란 위험도 딸려 온다. 그렇기 때문에 새로운 인터페이스를 만들 경우, 릴리스 전에 충분한 테스트를 거치고 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들어봐야 한다. 또한 인터페이스를 릴리스 후에 수정 가능성도 있겠지만, 절대 그렇게 만들지 말자.