[effective java] item 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

결론

자바 8에서 디폴트 메서드가 등장하면서, 인터페이스에 새 메서드를 추가하는 일이 비교적 간편해졌습니다.
하지만, 디폴트 메서드를 사용함으로써 위험이 완전히 사라진 것은 아닙니다.
새 인터페이스를 생성한다면, 최대한 많은 구현과 이를 사용하는 클라이언트를 만들고 테스트를 거침으로써 결함이 없는지를 판단한 후에 릴리스를 해야 합니다.
릴리스한 후라도 결함을 수정하는 게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안 됩니다.

 

 

설명

자바 7 까지의 세상에서는 모든 클래스가 "현재의 인터페이스에 새로운 메서드가 추가될 일은 영원히 없다" 라고 가정하고 작성됐습니다.

자바 8에 와서 메서드를 재정의하지 않고 인터페이스에 새 메서드를 추가할 수 있도록 디폴트 메서드가 등장했지만, 위험이 완전히 사라진 것은 아닙니다. 

 

인터페이스를 구현한 클래스에서 디폴트 메서드를 재정의 하지 않는다면, 디폴트 구현이 쓰이게 됩니다.

디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 '삽입'될 뿐입니다.

 

 

예시) 자바 8의 Collection 인터페이스에 추가된 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 구현체가 잘 어우러지는 것은 아닙니다.

 

 

문제 발생: 아파치의 SynchronizedCollection

대표적인 예가 org.apache.commons.collections4.collection.SynchronizedCollection입니다.

SynchronizedCollection?
자바 컬렉션을 동기화된 상태로 래핑하는 역할을 합니다. 이 클래스는 다중 스레드 환경에서 안전하게 컬렉션을 사용할 수 있도록 도와주는 도구입니다.

자바의 기본 컬렉션 프레임워크는 대부분 단일 스레드 환경을 가정하고 설계되어 있기 때문에, 멀티스레딩 환경에서 동시에 여러 스레드가 컬렉션에 접근하면 문제가 발생할 수 있습니다.
SynchronizedCollection은 이러한 문제를 방지하기 위해, 내부적으로 동기화 매커니즘을 사용하여 여러 스레드가 컬렉션을 안전하게 사용할 수 있도록 합니다.

즉, 기존의 컬렉션을 래핑하여 다중 스레드 환경에서의 동기화를 자동으로 처리할 수 있습니다. 
예를 들어, 다음은 SynchronizedCollection를 사용하여 동기화된 리스트를 생성하는 예시입니다.

public static void main(String[] args) {
    List<String> originalList = new ArrayList<>();
    Collection<String> synchronizedList = SynchronizedCollection.synchronizedCollection(originalList);

    // 다중 스레드에서 synchronizedList에 접근해도 동기화되어 안전하게 사용됨
}

이처럼 'SynchronizedCollection'은 Apache Commons Collections 라이브러리를 통해 제공되며, 멀티스레딩 환경에서 안전하게 컬렉션을 사용하려는 경우에 유용하게 활용될 수 있습니다. 

 

SynchronizedCollection에서 사용하는 동기화 매커니즘을 조금 더 자세히 살펴보겠습니다. 

아차피 버전은 컬렉션 대신, 클라이언트가 제공한 객체로 락을 거는 기능을 추가로 제공합니다.

즉, 모든 메서드에서 주어진 락 객체로 동기화를 한 후에 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스입니다.

 

 

 

 

아파치의 SynchronizedCollection 클래스는 removeIf 메서드를 재정의하지 않고 있습니다.

따라서 이 클래스를 자바 8과 함께 사용해서 removeIf의 디폴트 구현을 물려받아 호출된다면, 문제가 발생합니다. 

즉, 모든 메서드 호출을 알아서 동기화해주지 못합니다.

removeIf의 구현은 동기화에 관해 아무것도 모르므로 락 객체를 사용할 수 없습니다.

따라서 SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 디폴트 메서드인 removeIf를 호출하면 락 객체로 동기화를 하지 않은 메서드가 호출되었기 때문에 ConcurrentModificationException이 발생하거나 다른 예기지 못한 결과로 이루어질 수 있습니다.

 

 

자바 플랫폼 라이브러리에서 이런 문제를 해결하기 위해 일련의 조치를 취했습니다.

예를 들어, 인터페이스의 구현체에서 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했습니다.

예를 들어, SynchronizedCollection이 반환하는 클래스들은 removeIf를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 했습니다.

하지만 자바 플랫폼에 속하지 않은 제 3의 기존 컬렉션 구현체들은 이런 언어 차원의 인터페이스 변화에 발맞춰 수정될 기회가 없었으며, 그중 일부는 여전히 수정되지 않고 있습니다.

 

 

그 뿐 아니라, 디폴트 메서드는 컴파일에 성공하더라도, 기존 구현체에 런타임 오류를 일으킬 수 있습니다.

 

 

정리

기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 합니다.

추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지 않을지 심사숙고해야 함도 당연합니다.

또한 디폴트 메서드로 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도로 정의하면 안 됩니다.

이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 됩니다.

따라서 디폴트 메서드라는 도구가 생겼더라도 인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야 합니다.

 

새로운 인터페이스라면 릴리스 전에 반드시 테스트를 거쳐야 합니다.

수많은 개발자가 그 인터페이스를 나름의 방식으로 구현할 것이니, 여러분도 서로 다른 방식으로 최소한 세 가지는 구현해봐야 합니다.

또한 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들어봐야 합니다.

이런 작업들을 거치면 여러분은 인터페이스를 릴리스하기 전에, 즉 바로잡을 기회가 아직 남았을 때 결함을 찾을 수 있습니다.

인터페이스를 릴리스한 후라도 결함을 수정하는 게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안 됩니다.

 

 

---

출처

https://www.yes24.com/Product/Goods/65551284

이펙티브 자바 Effective Java 3/E - 예스24