아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

[chikeem90]

디폴트 메서드의 위험성

디폴트 메서드란 (참고)

• 자바 8에서 인터페이스가 디폴트 메서드를 선언할 수 있게되면서 인터페이스의 기존 구현체들을 깨뜨리지 않고 메서드를 추가할 수 있게 되었으나, 새로 선언한 디폴트 메서드가 모든 구현체와 매끄럽게 연동되지 않을 가능성이 있음.
• 예시> Collection 인터페이스에 predicate을 인자로 받아서 해당 조건이 true인 경우 remove를 하는 디폴트 메서드인 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;
    }

• 아파치 커먼즈 라이브러리에서 제공하는 SynchronizedCollection은 클라이언트가 제공한 객체로 락을 거는 Collection인데, 자바 API의 Collection을 상속하고 있음.

public class SynchronizedCollection<E> implements Collection<E>, Serializable {

• 4.3 버전을 확인해보면 자바 API의 Collection 인터페이스를 상속하고 있으나, removeIf를 오버라이드 하지 않고 있음. (4.4 버전에선 오버라이드하도록 개선됨).
• https://github.com/apache/commons-collections/blob/29d2e93966e7fb99a888a58ab43480e485dcdfc6/src/main/java/org/apache/commons/collections4/collection/SynchronizedCollection.java
• 클라이언트는 SynchronizedCollection을 만들고 removeIf 메서드를 호출할 경우 멀티스레드 환경에서 thread-safe 하게 동작할 것이라고 기대하지만, 실제로는 Collection의 removeIf를 그대로 사용하게 되는 것이기 때문에 thread-safe하게 동작하지 않음.
• 이렇듯 디폴트 메서드는 기존 구현체에 런타임 오류를 일으킬 수 있기 때문에 꼭 필요한 경우가 아닌 이상 피해야 함.

결론

• 디폴트 메서드라는 도구가 생겼더라도, (디폴트 메서드를 추가함에 따라 유발되는 사이드이펙이 있을 수 있으므로), 인터페이스를 설계할 때는 세심한 주의를 기울여야 한다.

[corock]

저는 해당 아이템의 골자를 크게 두 가지로 정리해보려고 합니다.

1. 기존에 작성된 인터페이스라면, default method 사용 시 이미 사용 중인 코드와의 하위 호환성을 고려해야 한다.
2. 새로 스펙을 정의하는 인터페이스라면, 설계할 때(특히, default method) 세심한 주의를 기울여야 한다.

아이템 주제와 관통하는 얘기지만, 설계하는 단계에서 구현하는 쪽을 생각해서 설계한다는 말이 과연 무엇을 기준으로 삼아 설계해야 할까요?

[Irisation23]

@corock 설계하는 단계에서 구현을 생각할 수 있는 방법중 하나는 미래 대비에서 온다고 생각합니다.

미래 대비는 변경을 예측하는 것이 아닌 변경을 수용할 수 있는 코드로 창조해야 하는 그 어떤 모토를 이야기 하고자 하는것이 아닐까 생각합니다. -by 객.사.오

default method 의 추가 이유중 하나는 기존 구현은 인터페이스의 메서드 구현으로는 개발의 한계에 봉착하게 되었고 이는 위에서 말한 미래 대비의 예측에 실패했다는 생각이 드네요.
그래서 완벽한 호환성을 유지 하는것을 목표로 하는것이 아닌 변경을 수용할 수 있는 방법으로 default method 를 선택하지 않았나 생각해 봅니다.

마지막으로 객체가 자율성을 띄게 된다면 객체간의 결합도가 낮아진다고 알고 있습니다.

• 결합도를 낮추기 위하는 방법중 하나는 객체의 책임 역시 자율적으로 부여하는 것입니다.

썬크림을 구매하는 고객이 있다고 가정해보죠.

• XXX 회사 썬크림을 구매하는 고객은 반드시 주말에는 현금 결제를 해야하고 평일에는 카드 결제를 해야한다.

라는 정책을 가지고 있는 회사가 있다고 가정해 봅시다.
해당 회사의 결제 방식에 앙심을 품은 고객중 하나는 회사의 전산실을 공격했고, 카드 결제를 할 수 없도록 막아 버렸습니다.
이제 XXX 회사 썬크림을 구매할 수 있는 방법은 주말에 현금 결제 를 하는 수 밖에 없습니다.
그 주 XXX 회사의 주말에 비상 회의가 열립니다. XXX회사의 투자유치 회사가 참여했고 회사 경영을 위기를 돌파하기 위해 요구사항을 요청합니다.
가상 계좌, 무통장 입금을 추가 해 달라.

이야기를 정리 해 보면 위의 정책으로 고객의 책임을 구체화 해버린다면 고객은 여러 혼선을 겪게 될것이며
정책을 변경하기 위해 유연하지 못한 대처를 할 수 밖에 없습니다.

다시 이야기로 돌아와 회사의 한 개발자가 내놓은 대책은 아래와 같습니다.

• XXX 회사 썬크림을 구매하는 고객은 결제만 하면 썬크림을 구매 할 수 있습니다.

해당 해법으로 선택한 개발자의 선택은 바로 추상화 였습니다. 여러가지 결제라는 책임을 추상화 시켜버렸습니다.
추상화가 잘 되어 있을수록 변경의 파급효과가 객체(위의 이야기에서는 고객) 내부로 캡슐화가 됩니다.
이는 곧 객체간의 결합도를 낮추는 결과를 도출하는 결과를 냈습니다.
객체가 본인의 책임(e.g 현금 결제, 카드 결제, 무통장 입금, 가상 계좌 입금)에 따라 자율적인 선택을 할 수 있게 된것이죠.

댓글이 좀 길었지만 한줄로 요약하자면
객체에게 자유를... 객체 당신이 해야할 일은 당신이 알아서 해라.
정도로 요약해 볼 수 있겠네요.

[JoisFe]

기존에 존재하지 않았던 default method가 생기며
인터페이스에 추상메서드를 추가하여 모든 구현체들이 해당 메서드를 구현해야하는데 만약 모든 구현체가 항상 같은 코드(기능)을 하는 경우 매우 비효율적 이였습니다.
하지만 default method가 생김으로써 이러한 문제를 해결하였죠

궁금한점이 정리하신대로 default 메서드가 모든 구현체와 매끄럽게 연동되지 않을 가능성 (default method 간 충돌) 의 문제가 생길 수 있는데
이러한 부분은 구현하는 클래스에서 default method를 자신의 상황에 맞게 잘 재정의 한다면 해결할 수 있지 않을까요?

정리 감사합니다.!