0. Introduction

• 이번 아이템에서는 이미 존재하는 인터페이스에 대해 default method를 추가하는 상황에서 발생할 수 있는 문제점을 알아봅니다.
• 더 나아가 이런 문제점을 통해 챕터에서 강조하는 인터페이스는 구현하는 쪽을 생각해 설계하라는 말에 대해 알아봅니다.

<aside> 💡 과정 목표

1. default method에 대해 세밀하게 이해해 봅시다.

2. 기존 인터페이스에 default method를 추가할 시 발생할 수 있는 여러 문제점들을 알아보고 왜 이런 일이 발생하는지를 이해해 봅시다.

3. 아이템의 메인 주제인 인터페이스는 구현하는 쪽을 생각해 설계하라는 말의 의미를 생각하고 알아봅시다.

</aside>

1. default method

1-1. default method와 인터페이스

• JDK 1.8 이전까지는 인터페이스에 새로운 메서드를 추가할 시에 반드시 인터페이스를 구현한 하위 클래스들이 깨지게됩니다.
• 이유는 간단합니다. 새로운 메서드를 추가하면 public abstract로 선언되며 abstract 키워드가 붙기 때문에 인터페이스를 구현한 하위 클래스들은 반드시 새로 추가된 메서드를 구현해야 하기 때문입니다.
• default method는 위와 같이 새로운 메서드를 추가할 시 구현체가 깨지는 문제를 어느 정도 해결하기 위해 나온 메서드입니다.
  • default method는 default type name(param)과 같이 선언할 수 있으며 내부에 구현 코드를 넣을 수 있습니다.
• default method로 새로운 메서드를 추가하게 되면 인터페이스를 구현하는 구현체 클래스들에도 동일하게 default method가 들어가게 됩니다.
  • 상속과 비슷하다 할 수 있습니다. 구현체 클래스에서 default method를 재정의하는 것이 아니라면 인터페이스에서 구현했던 default method는 그대로 구현체가 물려받게 됩니다.
• 이런 특성 덕분에 이제 인터페이스에 새로운 메서드를 넣는 것을 컴파일 에러를 최소화하며 넣어줄 수 있게 되었습니다.
• 하지만 여전히 위험성은 존재합니다.

1-2. default method 작성의 어려움

• 이미 존재하는 인터페이스에 default method를 작성해 추가해야 하는 경우 인터페이스를 이미 구현한 구현체들의 불변식에는 영향을 끼치지 않도록 해야 합니다.
• 하지만 모든 상황에 대해 불변식에 영향을 끼치지 않는 default method를 작성하는 것은 꽤 어려운 일입니다.
• 가까운 예시는 책에서도 소개한 Collection Framework입니다. Collection은 JDK 1.8에 새롭게 추가된 Ramda Expression를 활용하기 위해 많은 수의 default method가 추가되었습니다. 책에서 소개한 예시인 Collection 인터페이스의 removeIf() 메서드를 봅시다.

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;
    }

• removeIf() 메서드는 filter 라는 Predicate을 받습니다. 이때 Predicate는 Boolean Expression으로 조건식을 의미합니다. 이 조건에 값을 넣어 참이 반환된다면 그 원소를 삭제하도록 동작합니다.