[Java] 인터페이스

0. 학습 목적

• 인터페이스의 구성요소에 대해 이해한다.
• 인터페이스는 언제 쓰는지 이해한다.

1. 인터페이스란?

인터페이스 란, '무엇을 할 것인가' 에 대한 명세만 적혀있는 계약 형 추상 자료형이다.

(1) 계약이란?

계약은 실생활에서 상호 간에 지켜야 하는 약속을 말한다. 인터페이스는 사용자와, 또 그것을 구현하고자 하는 class와 두 번 계약을 하게 된다.

• 사용자와의 계약
  : 사용자가 인터페이스 내 원하는 매서드를 규칙에 맞게 호출하면, 사용자가 예상하는 결과를 반환 해줘야 한다.

• 구현체와의 계약
  : 구현체는 추상 매서드의 규칙 (인수, 반환값)을 준수하여 구현하여야 하고, 그것의 용도에 맞는 행동을 해야 한다.

(2) 인터페이스 활용의 효과

구현 분리와 느슨한 결합

A. 구현 분리 = 논리적 결합도 낮춤

인터페이스가 없었던 시절의 사용자와 구현체의 상호 작용을 생각해보자. 매서드에 대한 공통적인 명세가 없기 때문에, 사용자는 원하는 행동을 하는 매서드를 찾기 위해 모든 클래스를 탐방해야 한다. 이는 사용자가 클래스의 세부 구현 내용을 전부 알고 있어야 한다는 말이 된다.
반면 인터페이스가 사용자와 구현체의 경계면에 서게 되면, 사용자는 인터페이스의 명세만 알면 되지, 구현체의 세부 구현 내용을 몰라도 된다. 이는 논리적인 의미의 결합도를 낮춘다.

인터페이스를 USB에 대입해보자. 현재 우리가 사용하는 키보드, 마우스, 외장 하드 모두 동일한 USB를 사용하고 있다. 만약 USB가 없었다면 우리는 컴퓨터에 사용하는 모든 보조 장치 별 포트 구멍을 외우고 있어야 한다. 하지만 USB 덕에 그러한 불필요한 수고는 덜 수 있게 되었다.

B. 코드 상으로도 결합도를 낮춤

위의 사용자 파트를 고수준 모듈로 치환하면 코드 상으로도 결합도가 낮아짐을 이해할 수 있다. 인터페이스가 없는 OOP 환경에서 특정 서비스를 구현한다고 해보자. 이때 클래스 간의 관계는 항상 포함하는 (has a) 관계일 수 밖에 없다. 다음 예시를 보자.

a. 인터페이스를 활용하지 않았을 경우

public class Notification {

    public void sendMessage(String way, String title, String msg) 
    {
        switch (way) {
            case "email": {
                EmailService email = new EmailService();
                email.sending(title, msg);
                break;
            }
            case "kakaotalk": {
                KakaoService kakao = new KakaoService();
                kakao.sending(title, msg);
                break;
            }
            default: {
                throw new CustomException("요청하신 전송 방법은 존재하지 않습니다.");
            }
        }    
    }

    public void saveMessage(String title, String msg) {
        // 저장 로직
    }
}

여기서는 알리 서비스가 고수준 모듈이다. 이후 알림 서비스의 메시지 보내기 기능 구현을 위해 쓰이는 EmailService와 KakaoService가 저수준 모듈이라고 할 수 있다. 코드를 잘 보면 고수준 모듈이 저수준 모듈을 포함하고 있다.

이러면 저수준 모듈에서 오류가 나면, 오류가 고수준 모듈로 전파되어 고수준 모듈의 나머지 서비스 전체가 중단되는 것이 문제이다.

b. 인터페이스를 활용했을 경우

public class Notification {


    public void sendMessage(MessageSerivce messageService String title, String msg) 
    {
        messageService.sending(title, msg);
    }

    public void saveMessage(String title, String msg) {
        // 저장 로직
    }
}

// -- 밑에 3개는 각각 다른 파일 --

public interface MessageService {
    public void sending(String title, String msg)
}


public class EmailService implements MessageService {
    @Override
    public void sending(String title, String msg) {
        // 이메일 전송로직
    }
}

public class KakaoService implements MessageService {
    @Override
    public void sending(Stirng title, String msg) {
        // 카카오톡 전송 로직 
    }

}

위의 코드는 EmailService와 KakaoService를 MessageService 인터페이스를 상속 받도록 만들었다. 이후 고수준 모듈에서 메시지 전송 기능이 필요할 경우, 인터페이스를 통해 EmailService나 KakaoService를 주입받아 활용하고 있다.

이런 식으로 구현하면 EmailService나 KakaoService의 오류, 변경 사항이 고수준 모듈인 Notification에게 영향을 주지 않게 된다. 이는 서로간의 의존도가 약해졌으므로 결합도가 낮춰졌다고 할 수 있다.

[!info] DIP와 인터페이스
인터페이스의 두 번째 효과는 객체 지향 설계 원칙 중 하나인 DIP와도 연관이 깊다. (위에서 구현한 내용 또한 전략 패턴을 활용해 DIP를 구현한 것이다.) DIP는 고수준 모듈이 저수준 모듈에 의존해서는 안되며, 두 개의 모듈 모두 추상체에 의존하도록 하여 의존성의 방향을 역전 시키는 설계 원칙을 말한다.

2. 구성요소 뜯어보기

public interface 인터페이스 이름 {
    // -- 변수 부분 - 옵션
    public static final 타입 변수_이름 = 값;


    // -- 매서드 파트

    // 추상 매서드 - 필수!
    public abstract 타입 매서드_이름 (매개변수 목록);
    // 정적 매서드 - 옵션
    public static 타입 매서드_이름 (매개변수 목록);
    // default 매서드 - 옵션
    public default 타입 매서드_이름 (매개변수 목록) {
        // 구현체
    }
    // private 매서드 - 옵션
    private 타입 매서드_이름 (매개변수_목록) {

    }

}

인터페이스에 속할 수 있는 모든 구성원을 나타내면 위와 같다. 여기서 중요한 점은 인터페이스는 어떠한 서비스에 대한 명세라는 점이다. 따라서 그 명세를 담당하는 추상 매서드는 인터페이스에 최소 1개는 존재해야 한다. 나머지는 있어도 되고 없어도 되는 옵션들이다.

이제 하나하나 살펴보자.

(1) 멤버 변수는 상수만 가능

인터페이스의 멤버 변수는 상수만 가능하다. 만약에 개발자가 public, static, final을 생략했어도, 컴파일 시간에 이 3 키워드가 자동으로 추가된다. 이렇게 설계된 이유는 가변적인 값을 가질 경우, 인터페이스의 명세가 런타임에 수정되며 전체 구현체에게 혼동을 줄 수 있기 때문이다.
다음과 같은 특징을 가진다.

1. 상수는 인터페이스를 구현한 클래스에도 상속된다.
2. 상수를 참조변수로 쓰면 사실 변수처럼 쓸 수 있음.
3. 당연히 상수이기 때문에, 상속한 구현체 클래스들에서 덮어쓰기가 안됨.
   (같은 변수 타입 및 이름으로 덮어쓰기를 시도해도, 인터페이스와 구현체 각각 값이 따로 존재하게 된다.)

A. 상수는 인터페이스를 구현한 클래스에게 상속된다.

interface Outer {  
    int constant = 77;  
}  
class Inner implements Outer {   
}
public class Main {  
    public static void main(String[] args) throws IOException {  
        System.out.println(Inner.constant);  
    }  
}  

위와 같이 Outer 인터페이스의 상수는 그것의 구현 클래스인 Inner에서도 사용할 수 있는 것을 볼 수 있다. 다만 해당 정적 변수를 구현 클래스에서 활용하는 것은 상수의 출처를 알아보기가 어려움으로 주의해서 사용해야 한다.

B. 상수를 참조 변수로 선언해서 변수처럼 활용이 가능하다.

interface Outer {  
   ArrayList<Integer> list = new ArrayList<>();  
}  

class Inner implements Outer {  

}  

public class Main {  
    public static void main(String[] args) throws IOException {  
       Inner.list.add(22);  
        System.out.println(Inner.list);  
    }  
}

C. 인터페이스의 멤버 변수는 상수라 덮어쓰기가 안된다.

클래스 상속일 경우 클래스 필드 멤버끼리 상속되어 덮어 씌워지지만, 인터페이스의 필드들은 모두 상수라서 상속을 해도 전부 독립적으로 운용된다.

interface Iflower {
    int ex = 10; // 각각 public static final
}

interface IPlant extends Iflower {
    int ex = 20; // 각각 public static final
}

class Tulip implements IPlant {
    int ex = 30; // 그냥 인스턴스 변수
}

public class Main {
    public static void main(String[] args) {
        // 클래스 타입 객체로 ex 멤버에 접근하면, 클래스 인스턴스 변수로 접근
        Tulip t =  new Tulip();
        System.out.println(t.ex); // 30

        // 인터페이스 타입 객체로 멤버에 접근하면, 인터페이스 static 상수로 접근
        Iflower a = new Tulip();
        System.out.println(a.ex); // 10 - 좋지않은 방법
        System.out.println(Iflower.ex); // 10 - 클래스 static 처럼 '인터페이스.멤버' 로 접근

        IPlant b = new Tulip();
        System.out.println(b.ex); // 20 - 좋지않은 방법
        System.out.println(IPlant.ex); // 20 - 클래스 static 처럼 '인터페이스.멤버' 로 접근
    }
}

(2) 추상 매서드

인터페이스는 필수적으로 1개 이상의 추상 매서드를 가지고 있어야 한다. 또한 해당 인터페이스와 계약 관계를 가지는 구현 클래스들은 인터페이스의 모든 추상 매서드를 구현해야한다.

(3) static 매서드

구현체 클래스 자체와는 무관한 기능을 제공하기 위해 존재하는 매서드 형태이다.

• 용도
  : 사용자에게 편의를 제공하는 유틸리티 함수나 사용자 요구에 맞는 인터페이스 구현체를 쓰도록 유도하는 팩토리 패턴 매서드 등으로 활용하기 위해 사용된다.

• 특징

1. 소유 주체는 '인터페이스' 이다. (호출: 인터페이스_이름.정적_함수_이름())
2. 구현체 클래스에서 Overriding이 불가능하다. (만약 같은 매서드 시그니처를 선언해도 별도의 정적 매서드 취급을 받고 실행된다.)
3. 접근 제어자는 public 만 가능하다.

A. Overriding 불가

위와 같이 인터페이스 Outer의 static Method를 구현 클래스에서 Overriding하면 에러가 난다. 하지만 다음과 같이 어노테이션을 제거하면 잘만 돌아간다.

이 현상을 Overhidding이라고 한다. 부모 모듈의 정적 매서드와 똑같은 시그니처의 정적 매서드를 자식 모듈에서 만들면, 부모 모듈의 매서드를 상속 받아서 재정의하는 것이 아니라, 그냥 똑같은 이름의 다른 매서드를 만드는 것이다. 위의 예시에서도 Outer.print()와 Inner.print()는 아무런 관계가 없다.

(4) default 매서드

인터페이스 내에서 선언되지만 구현체를 가지는 매서드를 말한다. 뜻은 '가만히 놔두면 인터페이스에 적힌대로 돌아가는데, 바꾸고 싶으면 가져다 쓴 너희들이 구현해~' 이다.

• 생긴 이유
  : 이전 버전의 인터페이스 구현체와 신규 인터페이스의 호환성을 보장하기 위해서 생성되었다.
• 특징
  1. 소유 주체는 '인터페이스의 구현 객체' 이다. (호출: 구현_객체.default_method)
  2. Interface에서 default 매서드 구현 시 인스턴스 컨텍스트 활용이 가능하다. (this.)
  3. Overriding이 가능하다.

A. default 매서드가 어떻게 호환성을 보장한다는 거지?

a. java7 이전의 호환성 문제

default 매서드는 java8부터 등장하였는데, 이것이 없었던 java7 이전 버전에서 생겼던 문제를 보자. 만약 임의의 인터페이스에 새로운 추상 매서드를 붙인 경우 어떨까? 그것과 계약 관계에 있는 모든 클래스들에서 컴파일 오류가 날 것이다. 따라서 해당 인터페이스와 계약한 모든 클래스를 찾아서 추상 매서드를 구현하고 재컴파일 해야했다.
더해서, 만약 인터페이스를 만든 주체가 통제할 수 없는 계약 클래스들의 경우, (ex - 제 3자가 내가 만든 인터페이스를 활용하여 라이브러리를 만들고 배포함) 이러한 추후 수정 조차 불가능하여 오류의 연쇄작용이 일었다.

이러한 오류를 해결하기 위해, JDK 팀에서는 interface에 default 매서드를 만들었다.

b. default 매서드의 효과

이전 버전 인터페이스와 계약한 클래스들에게 새로운 매서드의 구현을 강제하지 않게 된다.

이미 구현 완료된 매서드가 인터페이스에 있으므로 계약 클래스들에게 재정의 책임이 없다. 또한 default 매서드는 자동 상속 받으므로, 이후 필요하게 된다면 . 호출로 바로 사용하면 된다.

public interface MyInterface {
    // 추상 메서드 (반드시 구현해야 함)
    void abstractMethod();

    // Default 메서드 (구현 선택사항)
    default void defaultMethod() {
        System.out.println("인터페이스의 기본 구현");
    }
}

public class MyClass implements MyInterface {
    // 추상 메서드만 구현하면 됨
    @Override
    public void abstractMethod() {
        System.out.println("추상 메서드 구현");
}

public class Main {
    public static void main(String[] args) {
        MyClass obj = new MyClass();
        obj.abstractMethod();    // "추상 메서드 구현"
        obj.defaultMethod();     // "인터페이스의 기본 구현" - 자동 상속!
    }
}

B. 소유 주체는 인터페이스가 아닌 계약 클래스의 구현체!

많은 사람들이 static 매서드와 헷갈려 하는 부분이 이것이다. default 매서드를 호출하려면 명확한 구현체가 존재해야 한다.

C. default 매서드 구현에 인스턴스 컨텍스트 사용이 가능하다.

default 매서드 구현할 때 내부에 변수를 선언 후 사용하거나 혹은 static 매서드를 활용하는 것을 자주 볼 수 있다. 이것 이외에도 해당 인터페이스의 구현 객체의 컨텍스트도 활용할 수 있다.

interface Color {  
    ArrayList<String> colors = new ArrayList<>();  
    void addRed();  
    void addBlue();  
    void addGreen();  

    default void makeRGBAndPrint(){  
        this.addRed();  
        this.addBlue();  
        this.addGreen();  
        System.out.println(colors);  
    }  
}

위처럼 this. 키워드를 활용해 자신의 추상 매서드들을 활용하여 default 매서드를 구현할 수 있다. 이렇게 인스턴스 컨텍스트를 활용해 구현하면, 객체에 따라 동적으로 행동하는 매서드를 만들 수 있다는 장점이 있다.

class RGB implements Color {  

    @Override  
    public void addRed() {  
        colors.add("RED");  
    }  

    @Override  
    public void addBlue() {  
        colors.add("BLUE");  
    }  

    @Override  
    public void addGreen() {  
        colors.add("GREEN");  
    }  
}

public class Main {  
    public static void main(String[] args) throws IOException {  
            Color c = new RGB();  
            c.makeRGBAndPrint();  
    }  
}

이후 위와 같이 default 매서드에 대한 재정의 없이 계약 클래스 객체를 선언하고, main에서 다음과 같이 호출하면 제대로 출력되는 것을 볼 수 있다.

C. Overriding이 가능하다.

default 매서드는 인스턴스 매서드 취급이기 때문에, 인터페이스와 계약한 클래스에서 충분히 재정의가 가능하다. 하지만 이렇게 되면 다중 상속이 가능한 인터페이스에서는 죽음의 다이아몬드 문제를 직면하게 된다.

a. 다이아몬드 문제

다음과 같이 MyMailService가 Gmail과 네이버 메일을 다중 상속했다고 하자. 마침 두 서비스 모두 sending이라는 default 매서드가 존재한다. 이때, MyMailService에서 super 키워드를 써서 부모의 구현 매서드를 사용한다고 하면 둘 중 어느 것이 사용될까?

위와 같이 자식 클래스가 다중 상속한 부모 클래스(혹은 인터페이스) 매서드 중 어느 것을 상속 받는지 모호해지는 문제 상황을 다이아몬드 문제라고 한다.

b. 클래스와 인터페이스 각각 상속 시, 충돌 나는 상황

자식 클래스가 인터페이스와 부모 클래스를 모두 상속하는 상황을 가정해보자. 이때 부모 클래스와 인터페이스의 특정 매서드의 시그니처가 충돌하는 상황이 발생했다. 그렇다면 Java는 무조건 모든 경우에서 부모 클래스의 매서드가 상속되고 인터페이스의 디폴트 매서드는 무시된다.

사전 설정이 다음과 같다고 가정하자.
인터페이스 I1과 그냥 클래스 C1이 있고, Child 클래스가 둘다 상속한다.

interface I1 {  
    public void func1();  
    default public void print(){  
        System.out.println("나는 인터페이스 'I1'의 디폴트 매서드 입니다.");  
    }  
}  

class C1 {  
    public void print() {  
        System.out.println("나는 클래스 C1의 일반 매서드 입니다.");  
    }  
}  

class Child extends C1 implements I1 {  
    @Override  
    public void func1() {}  
}

이때 다음과 같이 실행해보자.

1. 자식 클래스 참조 변수로 할당 받아서 상속 충돌나는 매서드 실행
2. 자식 클래스를 '부모 인터페이스' 로 캐스팅 이후 매서드 재실행

   public class Main {  
    public static void main(String[] args) throws IOException {  
        Child child = new Child();  
        child.print();  
        ((I1) child).print();  
    }  
   }

   

두 경우 다 무조건 클래스의 매서드가 실행되는 것을 볼 수 있다.

c. 인터페이스 두 개를 다중 상속 받아서 충돌나는 상황

이때는 무조건 충돌나는 default 매서드를 자식 클래스에서 재정의 해줘야 한다.

D. default 매서드와 static 매서드 비교

둘의 차이를 간단히 표로 나타내보았다.

구분	default 메서드	static 메서드
선언 키워드	default	static
소유 주체	인터페이스를 구현한 인스턴스	인터페이스 자체
호출 방식	obj.method()	InterfaceName.method()
오버라이드 가능 여부	가능 – 구현 클래스가 재정의해 특화 로직 구현	불가 – 구현체가 같은 시그니처를 선언해도 별도 정적 메서드로 취급
this 사용	가능(인스턴스 컨텍스트)	불가(정적 컨텍스트)
주요 용도	공통 로직 제공, API 확장 시 호환성 유지	유틸리티·팩토리 메서드 제공, 응집도 향상
다이아몬드 문제	다중 인터페이스가 같은 시그니처 보유 시 **컴파일 오류 → 구현체가 해결	해당 없음

(5) Private 매서드

java 9 이후부터는 인터페이스에서도 private 매서드가 사용 가능해졌다.

• 용도
  : default 매서드끼리의 혹은 static 매서드 끼리의 공통 로직 묶기.
  • private : default 매서드끼리의 공통 로직을 묶어 저장
  • private static: static 매서드끼리의 공통 로직을 묶어 저장

3. 인터페이스는 언제 사용할까?

클래스의 정체성보다 클래스의 행동이나 능력 표현을 중시해야할 경우 사용한다.
클래스 간의 상속 관계가 A is a B 라면, 클래스(A)와 인터페이스(B)간의 관계는 A is capable of B (A는 B를 할 수 있다.) 이다.

대표적인 인터페이스 사용의 경우 2가지를 소개하겠다.

1. 서로 연관이 없는 클래스들에게 공통적인 기능을 구현해야 할 때,
2. 행동에 대한 명세만 필요할 뿐 누가 그걸 행동하는지 알 필요가 없을 때

(1) 서로 연관 없는 클래스들에게 공통적인 기능 부여

서로 아에 연관이 없는 클래스들 사이에 공통적인 기능을 부여해야 하는 경우가 있다. 이때 오로지 공통 기능 명세를 위해 클래스 간에 상속 관게를 만든다면 오히려 프로그래밍의 복잡도를 높인다.

대표적인 예로는 Comparable<T> 인터페이스가 있다. 해당 인터페이스는 객체 간의 대소 관계 비교 기능을 나타내는 인터페이스이다. 이는 내가 만든 Student 클래스이건, 서드 파티 클래스 이건 상관없이 필요할 수 있다. 만약 대소 관계 비교가 필요한 모든 클래스를 서로 상속 관계로 잇는다면, 필요없는 연관 관계와 복잡성이 증가할 것이다. 따라서 위와 같은 인터페이스가 존재하는 것이다.

(2) 어떤 클래스가 구현 및 행동하는지 신경 쓸 필요가 없을 때.

클래스가 누구인지에 대한 정체성은 필요없이 누구든 그 행동을 하기만 하면될 때 인터페이스를 활용한다.

대표적인 예로 결제 기능을 들 수 있다.

// 결제 기능 계약만 정의
public interface PaymentGateway {
    PaymentResult processPayment(PaymentRequest request);
    void refund(String transactionId);
}

// 다양한 제3자가 구현
class KakaoPayGateway implements PaymentGateway { /* 카카오페이 구현 */ }
class NaverPayGateway implements PaymentGateway { /* 네이버페이 구현 */ }
class TossPayGateway implements PaymentGateway { /* 토스페이 구현 */ }

결제 기능은 누군가 그 역할을 수행하면 되지 누가 수행했는지는 알 필요가 없다. 이런 경우에는 상속 관계인 class보다 interface가 더 적합하다.

4. 핵심 요약

1. 인터페이스란 무엇을 할 것인가에 대한 명세만 적힌 계약형 추상 자료형이다.
   계약형이라 표현한 이유는 사용자와는 원하는 매서드 호출 시, 기대하는 결과를 반환한다는 계약을 맺고, 구현 클래스와는 인수를 받아 특정 행동을 수행하고 약속한 결과를 반환한다는 계약을 맺기 때문이다.
2. 인터페이스 활용 시 논리적으로도 코드 상으로도 결합도가 줄어든다.
   • 논리적 결합도 감소: 사용자가 자신이 사용하고픈 구현체를 찾기 위해 모든 구현체의 작동 방식과 반환 값을 알고 있어야 할 이유가 없어진다.
   • 코드 상 결합도 감소: 고수준 모듈이 저수준 모듈에 의존하고 있던 의존 흐름을, 두 모듈 모두 추상체에 의존하도록 하여 그 방향을 역전시킨다. 이는 저수준의 오류 전파에 따른 고수준 서비스 중단을 예방하고, 단위 별 유지 보수가 가능하게 만들기에 결합도가 감소한다.
3. 구성요소는 다음과 같다.
   1. 멤버 변수는 상수만 가능하다. -> 상수는 상속이 가능함.
   2. static 매서드는 인터페이스의 유틸리티 함수, 팩토리 매서드로 활용되며 상속이 안된다.
   3. default 매서드는 인터페이스의 이전 버전 구현체와의 호환성을 위해 출시되었고, 인터페이스 레벨에서도 구현체를 가진다. 오버라이딩이 가능하다. 하지만 죽음의 다이아몬드 문제를 조심해야 한다.
   4. private는 static이나 default 함수의 공통 로직 분리를 위해서만 쓰인다.
   5. 인터페이스의 사용 시점은 클래스의 정체성보다 클래스의 기능이나 행동이 중시되어야 하는 경우이다.

---

부록

A. 모르는 단어 정리

B. 참고 문서

• Infa 블로그 - 자바 인터페이스
• Baeldung - Using an Interface vs. Abstract Class in Java
• Baeldung - interface with default method vs abstract class in Java