인터페이스 설계 - 구현하는 개발자를 생각하자

# default Method 

• 자바 8 이전
  • 기존 구현체를 깨뜨리지 않고, 인터페이스에 메서드 추가 방법 전무후무
    - 인터페이스에 메서드 추가하면 대부분 컴파일 오류 발생 
    - 추가된 메서드가 기존 구현체에 존재할 가능성 희박 
• 자바 8 이후 
  • 기존 인터페이스에 메서드를 추가할 수 있도록 디폴트 메서드 추가 
    • 핵심 컬렉션 인터페이스들에 많은 디폴트 메서드 추가 for lambda 활용 
  • 디폴트 메서드 선언시, 그 인터페이스를 구현한 후에 디폴트 메서드를 재정의하지 않은 모든 클래스에서는 디폴트 구현이 사용

단, 디폴트 메서드는 구현 클래스에 대한 정보 없이 무작정 삽입(추가) 된 것이므로 주의해야 한다. 

• 자바 라이브러리의 디폴트 매서드는 코드 품질이 높고 범용적이므로 대부분의 상황에서 잘 작동
• 하지만, 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하는 것은 어려움

public interface Collection<E> extends Iterable<E> {
    default boolean removeIf(Predicate<? super E> filter) {
    // predicate 가 true 를 반환시 모든 원소 제거 기능 
        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;
    }
}

• 범용성을 생각한 구현, 하지만 현존하는 모든 Collection 구현체와 잘 어우러지지는 않으니 주의 
  
  → 자바 플랫폼 라이브러리 조치 
  구현한 인터페이스의 디폴트 메서드 재정의, 다른 메서드에서는 디폴트 메서드 호출 전 필요 작업 수행 

# 인터페이스 설계 및 개발의 주의 사항 

• 디폴트 메서드는 컴파일에 성공하더라도, 다른 기존 구현체에 런타임 오류 발생 가능성 존재
• 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요하지 않으면 지양
• 오히려 새로운 인터페이스를 만들어 표준적인 메서드 구현을 제공할 수 있고, 그 인터페이스를 더 쉽게 구현해 활용할 수 있는 또 다른 대안 
• 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나, 기존 메서드의 시그니처를 수정하는 용도가 아님 
• 디폴트 메서드 추가시 기존 구현체 충돌 고려 
• 새로운 인터페이스는 릴리스 전,  반드시 테스트 필요 
  • 본 책에서는 수 많은 개발자의 다른 구현 방식이 존재하므로 최소 세 가지의 다른 방식 구현 테스트 
  • 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트 다양한 테스트 
• 인터페이스를 릴리스 이후에 수정할 수 있다는 가능성에 기대는 개발자가 되어선 안된다.