인터페이스는 구현하는 쪽을 생각해 설계해라 - Effective Java[21]
🔗 디폴트 메소드 두둥 등장!!
자바 8 이전에는 기존 구현체를 깨뜨리지 않고는 인터페이스에 메소드를 추가 할 방법이 없었다.
인터페이스에 메소드를 추가하면 보통은 컴파일 오류가 나는데, 추가된 메소드가 우연히 기존 구현체에 이미 존재할 가능성은 아주 낮기 때문이다.
자바 8에 와서 기존 인터페이스에 메소드를 추가할 수 있도록 디폴트 메소드가 추가 되었지만, 위험이 완전히 사라진 것은 아니다.
💎 모든 상황에서 불변식을 해치지 않는 디폴트 메서드는 작성하기 어려워!
디폴트 메소드를 선언하면, 그 인터페이스를 구현한 후 디폴트 메소드를 정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.
하지만 모든 기존 구현체들과 매끄럽게 연동되리라는 보장은 없다.
자바 7까지의 세상에서는 모든 클래스가 “현재의 인터페이스에 새로운 메소드가 추가될 일은 영원히 없다”고 가정하고 작성됐으니 말이다.
디폴트 메소드는 구현 클래스에 대해 아무것도 모른 채 합의 없이 무작정 ‘삽입’될 뿐이다.
자바 8에서는 주로 람다를 활용하기 위해서 핵심 컬렉션 인터페이스들에 다수의 디폴트 메소드가 추가되었다.
자바 라이브러리의 디폴트 메소드는 코드 품질이 높고 범용적이라 대부분 상황에서 잘 작동한다.
하지만 생각 할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메소드를 작성하기는 어렵다.
💎 자바 8의 Collection 인터페이스에 추가된 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;
}
}
- 위는 자바 8의 Collection 인터페이스에 추가된 removeIf 메서드로, 주어진 boolean 함수(predicate; 프레디키트)가 true를 반환하는 모든 원소를 제거한다.
- 범용적으로 잘 구현되었지만, 현존하는 모든 Collection 구현체와 잘 어우러지는 것은 아니므로 주의해야 한다.
- 대표적인 예가 org.apache.commons.collections4.collection.SynchronizedCollection이다. 아파치 커먼즈 라이브러리의 이 클래스는 모든 메소드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼클래스다.
- 이 클래스를 자바 8과 함께 사용해서 removeIf의 디폴트 구현을 물려받게 된다면, 모든 메소드 호출을 알아서 동기화 해주지 못한다. removeIf의 구현은 동기화에 관해 아무것도 모르므로 락 객체를 사용할 수 없다.
- 따라서 SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removeIf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다.
- 자바 플랫폼 라이브러리에서는 이런 문제를 예방하기 위해 다음과 같은 조치를 취했다.
- 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다.
**💎 디폴트 메소드 주의 사항!! **
-
디폴트 메소드는 (컴파일에 성공하더라도) 기존 구현체에 런타임 오류를 일으킬 수 있다.
- 기존 인터페이스에 디폴트 메소드로 새 메소드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.
- 새로운 인터페이스를 만드는 경우라면 표준적인 메소드 구현을 제공하는 데 아주 유용한 수단이며, 그 인터페이스를 더 쉽게 구현해 활용할 수 있게끔 해준다.
- 디폴트 메소드는 인터페이스로부터 메소드를 제거하거나 기존 메소드의 시그니처를 수정하는 용도가 아님을 명심해야 한다.
- 이런 형태로 인터페이스를 변경하면 반드시 기존 클라이언트를 망가뜨리게 된다.
디폴트 메소드라는 도구가 생겼더라도 인터페이스를 설계 할 때는 여전히 세심한 주의를 기울여야 한다.
디폴트 메소드로 기존 인터페이스에 새로운 메소드를 추가하면 커다란 위험도 딸려 온다.
새로운 인터페이스라면 릴리즈 전에 반드시 테스트를 거쳐야 한다.
인터페이스를 릴리즈 한 후에라도 결함을 수정하는게 가능한 경우도 있겠지만,
절대 그 가능성에 기대서는 안 된다.
참조 - 이펙티브 자바 3/E - 조슈아 블로크
Comments