인터페이스는 구현하는 쪽을 생각해 설계하라 - [4장. 클래스와 인터페이스(아이템21)]

1. 개념 👻

  디폴트 메서드를 선언하면, 그 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.

  기존 인터페이스에 메서드를 추가하는 길이 열렸지만 모든 기존 구현체들과 매끄럽게 연동되리라는 보장은 없다. 자바 7까지의 세상에서는 모든 클래스가 "현재의 인터페이스에 새로운 메서드가 추가될 일은 영원히 없다"라고 가정하고 장성됐으니 말이다.

  디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작성 '삽입'될 뿐이다. 이번 글에서는 이런 경우 발생할 수 있는 문제 상황들을 살펴보고 그에 대한 해결책을 알아보자.

 

2. [문제 상황 1] 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어렵다. 🤖

  자바 8의 Collction 인터페이스에 추가된 removeIf 메서드를 예로 생각해 보자.

public interface Collection<E> extends Iterable<E> {
    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;
    }
}

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

  이 코드보다 더 범용적으로 구현하기도 어렵겠지만, 그렇다고 해서 현존하는 모든 Collection 구현체와 잘 어우러지는 것은 아니다.

  org.apache.commons.collections4.collection.SynchronizedCollecion을 생각해 보자. SynchronizedCollection 클래스가 removeIf의 디폴트 구현을 물려받게 된다면, 모든 메서드 호출을 알아서 동기화하지 못한다는 문제가 생기게 된다. removeIf의 구현은 동기화에 관해 아무것도 모르는 상태이기 때문이다.

  그래서 SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removeIf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다.

 

3. [문제 상황 2] 디폴트 메서드는 컴파일에 성공하더라도 기존 구현체에 런타임 오류를 일으킬 수 있다. 👾

  SuperClass, SubClass를 이용한 예시를 살펴보자.

public class SuperClass {

    public void hello() {
        System.out.println("hello class");
    }
}

----------

public class SubClass extends SuperClass {
}

----------

public static void main(String[] args) {

    SubClass subClass = new SubClass();
    subClass.hello();
}

  위의 코드를 동작시켜 보면 쉽게 예상할 수 있듯이 "hello class"가 출력된다. 그러면 SuperClass, SubClass, MarkerInterface를 이용한 아래 코드는 어떨까?

public class SuperClass {

    // 접근 제한자가 private라는 것을 확인하자.
    private void hello() {
        System.out.println("hello class");
    }
}

----------

public interface MarkerInterface {

    default void hello() {
        System.out.println("hello interface");
    }
}

----------

public class SubClass extends SuperClass implements MarkerInterface{
}

----------

public static void main(String[] args) {

    SubClass subClass = new SubClass();
    subClass.hello();
}

  SuperClass의 hello() 메서드가 private이므로 SubClass에서는 접근할 수 없다. 하지만 MarkerInterface에 디폴트 메서드로 hello()가 있으므로 이것을 이용하면 될 것이다.

  하지만, 실제 동작을 시켜보면 IllegalAccessError가 발생한다. 

  위에서 얘기한 생각의 흐름대로라면 당연히 MarkerInterface의 hello()를 사용할 거 같지만, 실제로는 SuperClass의 hello()를 사용하려고 하기 때문에 IllegalAccessError가 발생한 것이다. (메서드를 찾으려고 할 때 클래스가 인터페이스를 이기게 되어있기 때문이다.)

  즉, 이렇게 기존에 짜여진 자바 코드가 영향을 받을 수 있다.

 

4. 해결책 👽

  위와 같은 문제 상황들을 해결하기 위해서는 다음을 고려해야 한다.

---

• 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.
• 추가하려는 디폴트 메서드가 기존 구현체들과 충돌하지 않을지 심사숙고해야 함도 당연하다.

---

• 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아님을 명심해야 한다.
• 이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 된다.

---

• 새로운 인터페이스라면 릴리스 전에 반드시 테스트를 거쳐야 한다.
• 서로 다른 방식으로 최소한 세 가지는 구현해 보자.
• 인터페이스를 릴리스한 후라도 결함을 수정하는 게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안 된다.

---

 

해당 글은 백기선 님의 '이펙티브 자바 완벽 공략'을 참고하였습니다.