[이펙티브 자바] Item21. 인터페이스는 구현하는 쪽을 고려해 설계하라.

 

[이펙티브 자바] Item21. 인터페이스는 구현하는 쪽을 고려해 설계하라. 

 

자바8 전에는 인터페이스에 메서드를 추가할 방법이 없었는데 자바 8에 와서 기존 인터페이스에 메서드를 추가할 수 있게 됐다. 

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

이제 자바에서도 기존 인터페이스에 메서드를 추가할 수 있지만 모든 기존 구현체들과 매끄럽게 연동된다는 보장은 없다. 

 

 

 

- 기존 인터페이스에 디폴트 메서드 구현을 추가하는 것은 위험한 일이다. 

기존 인터페이스에 디폴트 메서드 구현을 추가하는 것은 위험하긴하다. 

왜냐하면 디폴트 메서드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 삽입되기 때문이다. 

 

자바 라이브러리의 디폴트 메서드는 코드 품질이 높고 범용적이라 대부분의 상황에서 잘 작동하지만 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어려운 법이다. 

 

 

/**
 * Removes all of the elements of this collection that satisfy the given
 * predicate.  Errors or runtime exceptions thrown during iteration or by
 * the predicate are relayed to the caller.
 *
 * @implSpec
 * The default implementation traverses all elements of the collection using
 * its {@link #iterator}.  Each matching element is removed using
 * {@link Iterator#remove()}.  If the collection's iterator does not
 * support removal then an {@code UnsupportedOperationException} will be
 * thrown on the first matching element.
 *
 * @param filter a predicate which returns {@code true} for elements to be
 *        removed
 * @return {@code true} if any elements were removed
 * @throws NullPointerException if the specified filter is null
 * @throws UnsupportedOperationException if elements cannot be removed
 *         from this collection.  Implementations may throw this exception if a
 *         matching element cannot be removed or if, in general, removal is not
 *         supported.
 * @since 1.8
 */
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;
}

자바 8 Collection 인터페이스에 추가된 removeIf 메서드를 예를 들어 보면 이 메서드는 주어진 불리언 함수 Predicate 가 true를 반환하는 모든 원소를 제거한다. 

이 코드에서 현존하는 모든 Collection 구현체와 잘 어울리는 것은 아닌데 SynchronizedCollection이 대표적인 예이다. 

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

 

근데 이 클래스에서 remveIf 디폴트 구현을 물려받게 된다면 예기치 못한 결과로 이어질 수 있다..!!

removeIf의 구현은 동기화에 관해서는 아무것도 모르기 때문에 락 객체를 사용할 수 없다. 

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

 

 

 

 

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

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

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

public class SubClass extends Superclass implements MakerInterface
{
   public static void main(String[] args)
   {
      SubClass subClass = new SubClass();
      subClass.hello(); 
   }
}

이 코드를 실행해보면 런타임 오류가 발생한다. 

'Exception in thread "main" java.lang.IllegalAccessError: class chapter03.item21.SubClass tried to access private method chapter03.item21.Superclass.hello()V'

 

항상 구체적인 것이 더 우선하게 되어있기 때문에 클래스가 인터페이스를 이기는데 이 규칙?을 따라서 Subclass에서 hello를 호출한 것은 인터페이스의 hello가 아니라 SuperClass의 hello이다. 근데 SuperClass의 hello는 private인데도 호출이 되는 에러? 버그가 있고, 

그 결과 이를 실행하면 private 메서드에 접근한다고 런타임 오류를 내는 것이다. 

 

 

 

 

📚 정리

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

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

반면에 새로운 인터페이스를 만드는 경우라면 표준적인 메서드 구현을 제공하는 것은 아주 유용한 수단이 되고, 인터페이스를 더 쉽게 구현해 할 수 활용할 수 있게 해준다.