기본 메서드와 호환성

인터페이스에 abstract 메서드를 추가하면 새 계약을 충족하는 메서드가 없는 구체 클래스는 재컴파일 때 구현을 추가해야 합니다. 이미 적합한 메서드를 갖거나 상속받는 클래스와 추상 클래스는 구분합니다.

기본 메서드는 인터페이스가 기본 구현을 제공해 기존 바이너리와 소스의 호환성을 높입니다.

구현을 공유하기에는 편리하지만 상태와 불변식이 필요한 핵심 동작까지 무분별하게 넣으면 규칙이 흐려집니다.

기본 메서드 충돌

서로 독립적인 두 인터페이스가 같은 notifyMessage 기본 메서드를 제공하면 Java는 어느 구현을 사용할지 결정할 수 없습니다.

아래 선언은 두 기본 메서드의 충돌을 해결하지 않아 Java 언어 규칙상 컴파일 오류입니다.

interface EmailChannel {
    default String notifyMessage(String value) {
        return "email:" + value;
    }
}

interface SmsChannel {
    default String notifyMessage(String value) {
        return "sms:" + value;
    }
}

public final class ConflictingDefaultMethodsFailure implements EmailChannel, SmsChannel {
    public static void main(String[] args) {
        System.out.println(new ConflictingDefaultMethodsFailure().notifyMessage("hello"));
    }
}

구현 클래스가 메서드를 재정의해 하나를 선택하거나 두 기본 구현을 조합해야 합니다.

충돌한 구현 가운데 하나를 암묵적으로 선택하지 않으므로 인터페이스 규칙의 변경이 안전하게 드러납니다.

default가 인터페이스 진화를 돕는 과정

기존 Notifier에 추상 메서드 send만 있고 EmailNotifier와 LogNotifier가 이를 구현한다고 가정합니다.

두 구현 클래스에 sendUrgent를 충족하는 구현이 없다면, 추상 메서드 추가 후 재컴파일할 때 이를 구현해야 합니다.

send를 조합한 기본 메서드로 추가하면 기존 구현을 수정하지 않고도 긴급 전송 기능을 제공할 수 있습니다.

public final class EvolvingNotifierInterface {
    private interface Notifier {
        void send(String message);

        default void sendUrgent(String message) {
            send("URGENT: " + message);
        }
    }

    private static final class ConsoleNotifier implements Notifier {
        @Override
        public void send(String message) {
            System.out.println("console=" + message);
        }
    }

    public static void main(String[] args) {
        Notifier notifier = new ConsoleNotifier();
        notifier.send("normal");
        notifier.sendUrgent("disk full");
    }
}

기본 메서드는 기존의 추상 메서드 계약만 사용해 구현해야 합니다.

특정 구현 타입으로의 형변환이나 숨겨진 가변 상태에 의존하면 다른 구현에서 깨집니다.

새 기능이 모든 구현에 타당한 기본 의미를 가질 때 적합합니다.

예시 예제의 ConsoleNotifier는 sendUrgent를 선언하지 않습니다. 상속한 기본 메서드가 메시지 앞에 URGENT:를 붙이고 send를 호출하면 실제 ConsoleNotifier.send가 console=URGENT: disk full을 출력합니다. 인터페이스 기본 구현이 구현 객체의 send를 호출한 것이며 ConsoleNotifier를 새로 만들거나 상태 필드를 추가한 것이 아닙니다.

클래스 우선 규칙

상위 클래스의 구체 메서드와 인터페이스의 기본 메서드가 같은 시그니처라면 클래스 메서드가 우선합니다.

인터페이스의 기본 메서드가 Object 계열 동작을 덮어 클래스 계층의 의미를 바꾸지 못하게 하는 규칙입니다.

public final class ClassWinsDefaultResolution {
    private interface Named {
        default String name() {
            return "interface";
        }
    }

    private static class Base {
        public String name() {
            return "class";
        }
    }

    private static final class Child extends Base implements Named {}

    public static void main(String[] args) {
        System.out.println(new Child().name());
    }
}

출력은 class입니다.

상위 클래스가 같은 메서드를 추상 메서드로 선언했다면 기본 메서드가 자동으로 그 요구를 채우지 않습니다. 구체 하위 클래스가 구현해야 합니다.

equals, hashCode, toString 같은 Object 메서드는 기본 메서드로 제공할 수 없습니다.

하위 인터페이스 우선 규칙

Parent를 상속한 Child가 같은 메서드를 재정의하면 더 구체적인 Child의 구현이 우선합니다.

구현 클래스가 Parent와 Child를 모두 implements에 적더라도 이 관계는 바뀌지 않습니다.

서로 상속 관계가 없는 두 기본 메서드가 충돌하는 경우에는 구현 클래스가 직접 해결해야 합니다. 하위 인터페이스가 메서드를 다시 추상화한 경우에도 구체 클래스의 구현이 필요할 수 있습니다.

public final class SpecificDefaultResolution {
    private interface BasicFormatter {
        default String format(String value) {
            return value;
        }
    }

    private interface UpperFormatter extends BasicFormatter {
        @Override
        default String format(String value) {
            return value.toUpperCase();
        }
    }

    private static final class ReportFormatter implements UpperFormatter {}

    public static void main(String[] args) {
        System.out.println(new ReportFormatter().format("stream"));
    }
}

결과는 STREAM입니다.

인터페이스 계층 자체가 기능의 구체화를 나타낼 때 이 규칙이 자연스럽습니다.

충돌 해결과 super 호출

구현 클래스는 EmailChannel.super.notifyMessage(value)처럼 원하는 인터페이스의 기본 구현을 호출할 수 있습니다.

두 구현을 합치거나 완전히 새로운 정책을 제공할 수도 있습니다.

Interface.super는 현재 클래스 또는 인터페이스의 직접 상위 인터페이스를 대상으로 합니다. 더 구체적인 직접 상위 클래스·인터페이스가 있으면 이를 건너뛰어 조상 기본 구현을 선택할 수 없습니다.

public final class ResolvedNotificationChannels {
    private interface Email {
        default String send(String value) {
            return "email:" + value;
        }
    }

    private interface Sms {
        default String send(String value) {
            return "sms:" + value;
        }
    }

    private static final class Both implements Email, Sms {
        @Override
        public String send(String value) {
            return Email.super.send(value) + " | " + Sms.super.send(value);
        }
    }

    public static void main(String[] args) {
        System.out.println(new Both().send("release"));
    }
}

충돌 해결 방법이 클래스에 명시되므로 API를 읽는 사람이 다중 채널 정책을 확인할 수 있습니다.

두 기본 구현에 부수 효과가 있다면 호출 순서와 부분 실패 정책을 별도로 설계해야 합니다.

상속 후보를 찾는 일과 실행할 구현을 고르는 일을 나눠 보세요. 예제의 Child는 Base의 public name을 이미 물려받아 Named의 default와 맞더라도 class를 선택합니다. ReportFormatter는 UpperFormatter가 BasicFormatter보다 구체적인 관계라 STREAM을 반환합니다. Both는 Email·Sms 사이의 상속 우열이 없어 자체 재정의에서 두 super 호출을 순서대로 조합합니다. JLS의 인터페이스 메서드 상속 규칙과 코드의 선언 관계를 함께 대조하세요.

독립 확인: 클래스에 같은 시그니처의 메서드를 직접 선언하지 않는다고 정합니다. 첫 경우는 Base가 추상 name만 선언하고 Named는 default name을 제공합니다. 둘째는 UpperFormatter가 format을 다시 추상 선언합니다. 구체 Child·ReportFormatter가 기존 모습 그대로 컴파일되나요?

기본 메서드를 올바르게 쓰는 범위

기본 메서드는 기존 추상 메서드를 조합한 편의 기능, 호환 가능한 작은 기능 확장, 구현 클래스와 무관한 공통 알고리즘에 적합합니다.

인터페이스에는 인스턴스 필드가 없으며 선언한 필드는 public static final입니다. 객체별 상태가 필요한 불변식은 구현 클래스가 맡고, 인터페이스에는 protected 도우미도 둘 수 없습니다.

private 인터페이스 메서드를 사용하면 기본 메서드 사이의 구현 중복을 줄일 수 있습니다.

모든 구현에 아무 동작도 하지 않는 기본 메서드를 제공하면 새 기능의 누락이 감춰집니다.

예를 들어 감사 기능을 반드시 구현해야 한다면 추상 메서드를 추가하고 기존 구현을 마이그레이션하는 편이 더 정직합니다.

호환성을 깨더라도 정확성을 우선해야 하는 버전 변경도 있습니다.

API 진화의 소스·바이너리·동작 호환성

JLS는 기본 메서드 추가를 기존 바이너리와 호환되는 변경으로 분류하지만, 재컴파일 시 충돌하거나 기존 바이너리의 메서드 호출 시 IncompatibleClassChangeError가 발생하는 경우까지 배제하지는 않습니다. 기존 클래스의 같은 시그니처 메서드가 선택되는지도 확인합니다.

하위 라이브러리와의 통합 검증도 수행합니다.

새 기본 메서드가 기존 메서드의 호출 횟수나 예외를 바꾸면 동작 호환성이 깨집니다.

인터페이스를 공개 라이브러리로 배포한다면 메서드 이름, 제네릭 타입 소거, 향후 이름 충돌 가능성을 검토합니다.

단순히 구현 중복을 줄이는 믹스인 용도로 기본 메서드를 남발하지 않습니다.

연습 문제

Exporter의 추상 메서드 export(String)을 이용해 최대 세 번 시도하는 기본 메서드 exportWithRetry를 만드세요.

기존 FlakyExporter는 새 메서드를 따로 구현하지 않아도 동작해야 합니다.

실패 횟수와 최종 성공을 재현하세요.

public final class DefaultRetryExporterSolution {
    private interface Exporter {
        boolean export(String value);

        default boolean exportWithRetry(String value) {
            for (int attempt = 1; attempt <= 3; attempt++) {
                if (export(value)) {
                    return true;
                }
            }
            return false;
        }
    }

    private static final class FlakyExporter implements Exporter {
        private int calls;

        @Override
        public boolean export(String value) {
            calls++;
            System.out.println("attempt=" + calls + ", value=" + value);
            return calls >= 2;
        }
    }

    public static void main(String[] args) {
        Exporter exporter = new FlakyExporter();
        System.out.println("success=" + exporter.exportWithRetry("report"));
    }
}

독립 확인: 새 Exporter는 첫 세 export 호출이 모두 false이고 넷째부터 true라고 정합니다. 새 객체의 exportWithRetry를 한 번 호출하면 반환값과 누적 호출 횟수는 무엇인가요? 같은 객체로 두 번째 호출을 하면 어떤가요? 별도로 첫 export에서 예외를 던진다면 세 번을 채우나요?

기본 메서드는 인터페이스를 발전시키면서 호환성을 유지하는 도구입니다.

클래스 메서드 우선, 더 구체적인 인터페이스 우선, 무관한 인터페이스의 충돌은 명시적 재정의로 해결한다는 규칙을 이해하고 모든 구현에 타당한 기본 동작에만 사용해야 합니다.