🐹 chap13. 디폴트 메서드

인터페이스를 변경(새로운 메서드 추가 등)하고자 할 때 해당 인터페이스를 상속한 모든 클래스를 고쳐야 한다면 매우 당황스러울 것이다.

자바 8에서는 이 문제를 해결하는 새로운 기능을 제공한다. 자바 8에서는 기본 구현을 포함하는 인터페이스를 정의하는 두 가지 방법을 제공한다.

1. 인터페이스 내부에 정적 메서드 사용
2. 인터페이스의 기본 구현을 제공할 수 있도록 디폴트 메서드 기능 사용

메서드 구현을 포함하는 인터페이스를 정의할 수 있다. 결과적으로 기존 인터페이스를 구현하는 클래스는 자동으로 인터페이스에 추가된 새로운 메서드의 디폴트 메서드를 상속받게 된다. 이렇게 하면 기존의 코드 구현을 바꾸도록 강요하지 않으면서도 인터페이스를 바꿀 수 있다.

이와 같은 방식으로 두가지 예로 List 인터페이스의 sort와 Collection 인터페이스의 stream 메서드가 있다.

List 인터페이스의 sort 메서드는 자바 8에서 새로 추가된 메서드다. 다음은 sort의 구현 코드다.

default void sort(Comparator<? super E> c) {
    Collections.sort(this, c);
}

반환 형식 void 앞에 default라는 새로운 키워드가 등장했다.

default 키워드는 해당 메서드가 디폴트 메서드임을 가리킨다. 여기서 sort 메서드는 Collections.sort 메서드를 호출한다. 이 메서드 덕분에 리스트에서 직접 sort를 호출할 수 있게 되었다.

List<Integer> numbers = Arrays.asList(3, 5, 1, 2, 6);
numbers.sort(Comparator.naturalOrder()); //sort는 List 인터페이스의 디폴트 메서드다

naturalOrder → 자연순서(표준 알파벳 순서)로 요소를 정렬할 수 있도록 Comparator 객체를 반환하는 Comparator 인터페이스에 추가된 새로운 정적 메서드다.

다음은 Collection의 stream 메서드 정의 코드다.

default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}

stream 메서드는 내부적으로 StreamSupport.stream이라는 메서드를 호출해서 스트림을 반환한다. stream 메서드의 내부에서는 Collection 인터페이스의 다른 디폴트 메서드 spliterator도 호출한다.

디폴트 메서드는 주로 라이브러리 설계자들이 사용한다. 아래 그림처럼 디폴트 메서드를 이용하면 자바 API의 호환성을 유지하며 라이브러리를 바꿀 수 있다.

인터페이스에 메서드를 추가하면 여러 문제가 발생했었다.

→ 인터페이스에 새로 추가된 메서드를 구현하도록 인터페이스를 구현하는 기존 클래스를 고쳐야 했기 때문이다.

본인이 직접 인터페이스와 이를 구현하는 클래스를 관리할 수 있는 상황이라면 이 문제를 어렵지 않게 해결할 수 있지만 인터페이스를 대중에 공개했을 때는 상황이 다르다.

그래서 디폴트 메서드가 탄생하였다.

디폴트 메서드를 이용하면 인터페이스의 기본 구현을 그대로 상속하므로 인터페이스에 자유롭게 새로운 메서드를 추가할 수 있게 된다.

디폴트 메서드는 다중 상속이라 유연성을 제공하면서 프로그램 구성에도 도움을 준다(이제 클래스는 여러 디폴트 메서드를 상속받을 수 있게 되었다)

13.1 변화하는 API

ex) 라이브러리 설계

• 모양의 크기를 조절하는 데 필요한 setHeight, setWeight, getHeight, getWidth, setAbsoluteSize 등의 메서드를 정의하는 Resizable 인터페이스
• Rectangle이나 Square처럼 Resizable을 구현하는 클래스 제공
• 라이브러리가 인기를 얻으며 일부 사용자는 직접 Resizable 인터페이스를 구현하는 Ellipse라는 클래스 구현

API를 릴리즈 한 후 Resizable에 몇 가지 기능이 부족하다는 사실을 알게되었다. 예를 들어 Resizable 인터페이스에 크기 조절 인수로 모양의 크기를 조절할 수 있는 setRelativeSize라는 메서드가 있으면 좋을 것 같다. 그래서 Resizable에 setRelativeSize를 추가한 다음에 Square과 Rectangle 구현도 고쳤다.

이렇게 되면 Resizable 인터페이스를 구현한 사용자는 어떻게 되는 걸까?

안타깝게도 라이브러리 사용자가 만든 클래스는 우리가 어떻게 할 수는 없다.

자바 라이브러리 설계자가 라이브러리를 바꾸고 싶을 때 같은 문제가 발생한다.

13.1.1 API 버전 1

Resizable 인터페이스 초기 버전은 다음과 같은 메서드를 포함한다.

public interface Resizable extends Drawable {
    int getWidth();
    int getHeight();
    void setWidth(int width);
    void setHeight(int height);
    void setAbsoluteSize(int width, int height);
}

사용자 구현

우리 라이브러리를 즐겨 사용하는 사용자 중 한 명은 직접 Resizable을 구현하는 Ellipse 클래스를 만들었다.

public class Ellipse implements Resizable {
    ...
}

이 사용자는 다양한 Resizable 모양(자신이 만든 Ellipse를 포함하여)을 처리하는 게임을 만들었다.

public class Game {
    public static void main(String...args) {
        // 크기를 조절할 수 있는 모양 리스트
        List<Resizable> resizableShapes =
            Arrays.asList(new Square(), new Rectangle(), new Ellipse());
        Utils.paint(resizableShapes);
    }
}

public class Utils {
    public static void paint(List<Resizable> l) {
        l.forEach(r -> {
            r.setAbsoluteSize(42, 42); //각 모양에 setAbsoluteSize 호출
            r.draw();
        });
    }
}

13.1.2 API 버전 2

몇 개월이 지나자 Resizable을 구현하는 Square와 Rectangle 구현을 개선해달라는 많은 요청을 받았다. 그래서 다음처럼 API 버전 2를 만들었다.

public interface Resizable {
    int getWidth();
    int getHeight();
    void setWidth(int width);
    void setHeight(int height);
    void setAbsoluteSize(int width, int height);
    // API 버전2에 추가된 새로운 메서드
    void setRelativeSize(int wFactor, int hFactor);
}

사용자가 겪는 문제

Resizable을 고치면 몇 가지 문제가 발생한다.

1. Resizable을 구현하는 모든 클래스는 setRelativeSize 메서드를 구현해야 한다. (하지만 라이브러리 사용자가 직접 구현한 Ellipse는 serRelativeSize 메서드를 구현하지 않는다.)

   → 인터페이스에 새로운 메서드를 추가하면 바이너리 호환성은 유지된다.

   (바이너리 호환성: 새로 추가된 메서드를 호출하지만 않으면 새로운 메서드 구현이 없이도 기존 클래스 파일 구현이 잘 동작한다.)

   하지만 언젠가 누군가는 Resizable을 인수로 받는 Utils.paint에서 setRelativeSize를 사용하도록 코드를 바꿀 수 있다. 이때 Ellipse 객체가 인수로 전달되면 Ellipse는 setRelativeSize 메서드를 정의하지 않았으므로 런타임에 다음과 같은 에러가 발생할 것이다.

    Exception in thread "main" java.lang.AbstractMethodError: lambdasinaction.chap9.
    Ellipse.setRelativeSize(II)V
   

2. 사용자가 Ellipse를 포함하는 전체 애플리케이션을 재빌드할 때 다음과 같은 컴파일 에러가 발생한다.

    lambdasinaction/chap9/Ellipse.java:6: error: Ellipse is not abstract and does not
    override abstract method setRelativeSize(int, int) in Resizable
   

   공개된 API를 고치면 기존 버전과 호환성 문제가 발생한다. 이런 이유 때문에 공식 자바 컬렉션 API 같은 기존의 API는 고치기 어렵다. 물론 API를 바꿀 수 있는 몇 가지 대안이 있지만 완벽한 해결책은 될 수 없다.

   예를 들어 자신만의 API를 별도로 만든 다음 예전 버전과 새로운 버전을 직접 관리하는 방법도 있다. → 여러 가지로 불편한 점

   (1) 라이브러리 관리 복잡

   (2) 사용자는 같은 코드에 예전 버전과 새로운 버전 두 가지 라이브러리를 모두 사용해야 함

   결국 프로젝트에서 로딩해야 할 클래스 파일이 많아지면서 메모리 사용과 로딩 시간 문제가 발생한다.

디폴트 메서드로 이 모든 문제를 해결할 수 있다.

디폴트 메서드를 이용해서 API를 바꾸면 새롭게 바뀐 인터페이스에서 자동으로 기본 구현을 제공하므로 기존 코드를 고치지 않아도 된다.

13.2 디폴트 메서드란 무엇인가?

자바 8에서는 호환성을 유지하면서 API를 바꿀 수 있도록 새로운 기능인 디폴트 메서드를 제공한다. 이제 인터페이스는 자신을 구현하는 클래스에서 메서드를 구현하지 않을 수 있는 새로운 메서드 시그니처를 제공한다.

인터페이스를 구현하는 클래스에서 구현하지 않은 메서드는 인터페이스 자체에서 기본으로 제공한다.(그래서 구현이 필수가 아님)

디폴트 메서드

• default라는 키워드로 시작
• 다른 클래스에 선언된 메서드처럼 메서드 바디 포함

ex) 컬렉션 라이브러리에 Sized 인터페이스 정의

public interface Sized {
    int size();
    default boolean isEmpty() { // 디폴트 메서드
        return size() == 0;
    }
}

이제 Sized 인터페이스를 구현하는 모든 클래스는 isEmpty의 구현도 상속받는다. 즉, 인터페이스에 디폴트 메서드를 추가하면 소스 호환성이 유지된다.

결론적으로 디폴트 메서드를 이용해 setRelativeSize의 디폴트 구현을 제공하면 호환성을 유지하며 라이브러리를 고칠 수 있다.

default void setRelativeSize(int wFactor, int hFactor) {
    setAbsoluteSize(getWidth() / wFactor, getHeight() / hFactor);

• 추상 클래스와 인터페이스의 차이
  1. 클래스는 하나의 추상 클래스만 상속받을 수 있지만 인터페이스는 여러 개 구현할 수 있다.
  2. 추상 클래스는 인스턴스 변수(필드)로 공통 상태를 가질 수 있다. 하지만 인터페이스는 인스턴스 변수를 가질 수 없다.

• Quiz. removeIf

  여러분이 자바 언어와 API의 달인이라고 가정하자. 어느 날 다수의 사용자로부터 ArrayList.TreeSet, LinkedList 및 다른 모든 컬렉션에서 사용할 수 있는 removeIf 메서드를 추가해달라는 요청을 받았다. removeIf 메서드는 주어진 프레디케이트와 일치하는 모든 요소를 컬렉션에서 제거하는 기능을 구행한다. 새로운 removeIf를 기존 컬렉션 API에 가장 적절하게 추가하는 방법은 무엇일까?

  • 정답

    우선 반대로 컬렉션 API를 고치는 가장 좋지 않은 방법은 무엇일까? 컬렉션 API의 모든 구현 클래스에 removeIf를 복사&붙여넣기 하는 방법이다.

    다른 방법은 없을까? 모든 컬렉션 클래스는 java.util.Collection 인터페이스를 구현한다. 그러면 Collection 인터페이스에 메서드를 추가할 수 있을까? 지금까지 확인한 것처럼 디폴트 메서드를 인터페이스에 추가함으로써 소스 호환성을 유지할 수 있다. 그러면 Collection을 구현하는 모든 클래스(물론 컬렉션 라이브러리의 클래스뿐 아니라 Collection 인터페이스를 직접 구현한 사용자 클래스도 포함)는 자동으로 removeIf를 사용할 수 있게 된다.

      default boolean removeIf(Predicate<? super E> filter) {
          boolean removed = false;
          Iterator<E> each = iterator();
          while(each.hasNext()) {
              if(filter.test(each.next())) {
                  each.remove();
                  removed = true;
              }
          }
          return removed;
      }
    

13.3 디폴트 메서드 활용 패턴

13.3.1 선택형 메서드

잘 사용하지 않는 기능(ex. remove)에는 기능을 무시하고 빈 구현을 제공했었다.

디폴트 메서드를 이용하면 remove 같은 메서드에 기본 구현을 제공할 수 있으므로 인터페이스를 구현하는 클래스에서 빈 구현을 제공할 필요가 없다. 예를 들어 자바 8의 Iterator 인터페이스는 다음처럼 remove 메서드를 정의한다.

interface Iterator<T> {
    boolean hasNext();
    T next();
    **default void remove() {
        throw new UnsupportedOperationException();
    }**
}

기본 구현이 제공되므로 Iterator 인터페이스를 구현하는 클래스는 빈 remove 메서드를 구현할 필요가 없어졌고, 불필요한 코드를 줄일 수 있다.

13.3.2 동작 다중 상속

디폴트 메서드를 이용하면 기존에는 불가능했던 동작 다중 상속 기능도 구현할 수 있다.

다음처럼 클래스는 다중 상속을 위해 기존 코드를 재사용할 수 있다.

자바에서 클래스는 한 개의 다른 클래스만 상속할 수 있지만 인터페이스는 여러 개 구현할 수 있다. 다음은 자바 API에 정의된 ArrayList 클래스다.

// 한 개의 클래스 상속, 네 개의 인터페이스를 구현한다. 
public class ArrayList<E> extends AbstractList<E>
    implements List<E>, RandomAccess, Cloneable, Serializable {
}

다중 상속 형식

여기서 ArrayList는 한 개의 클래스를 상속받고, 여섯 개의 인터페이스를 구현한다. 결과적으로 ArrayList는 AbstractList, List, RandomAccess, Cloneable, Serializable, Iterable, Collection의 서브 형식이 된다. 따라서 디폴트 메서드를 사용하지 않아도 다중 상속을 활용할 수 있다.

자바 8에서는 인터페이스가 구현을 포함할 수 있으므로 클래스는 여러 인터페이스에서 동작(구현 코드)을 상속받을 수 있다.

기능이 중복되지 않는 최소의 인터페이스

ex) 회전X, 크기 조절O 모양 / 회전O, 움직임O, 크기 조절X

이를 구현하려면 먼저 setRotationAngle과 getRotationAngle 두 개의 추상 메서드를 포함하는 Rotatable 인터페이스를 정의한다. 인터페이스는 다음 코드에서 보여주는 것처럼 setRotationAngle과 getRotationAngle 메서드를 이용해서 디폴트 메서드 rotateBy도 구현한다.

public interface Rotatable {
    void setRotationAngle(int angleInDegrees);
    int getRotationAngle();
    // rotateBy 메서드의 기본 구현
    default void rotateBy(int angleInDegrees) {
        setRotationAngle((getRotationAngle() + angleInDegrees) % 360);
    }
}

Rotatable을 구현하는 모든 클래스는 setRotationAngle과 getRotationAngle의 구현을 제공해야 한다. 하지만 rotateBy는 기본 구현이 제공되므로 따로 구현을 제공하지 않아도 된다.

마찬가지로 두 가지 인터페이스 Moveable과 Resizable을 정의해야 한다. 두 인터페이스 모두 디폴트 구현을 제공한다.

public interface Moveable {
    int getX();
    int getY();
    void setX(int x);
    void setY(int y);

    default void moveHorizontally(int distance) {
        setX(getX() + distance);
    }

    default void moveVertically(int distance) {
        setY(getY() + distance);
    }
}

public interface Resizable {
    int getWidth();
    int getHeight();
    void setWidth(int width);
    void setHeight(int height);
    void setAbsoluteSize(int width, int height);

    default void setRelativeSize(int wFactor, int hFactor) {
        setAbsoluteSize(getWidth() / wFactor, getHeight() / hFactor);
    }
}

인터페이스 조합

움직일 수 있고, 회전할 수 있으며, 크기를 조절할 수 있는 괴물 클래스 구현

public class Monster implements Rotatable, Moveable, Resizable {
    ... // 모든 추상 메서드의 구현은 제공해야 하지만 디폴트 메서드의 구현은 제공할 필요가 없다
}

Monster 클래스는 Rotatable, Moveable, Resizable 인터페이스의 디폴트 메서드를 자동으로 상속받는다(rotateBy, moveHorizontally, moveVertically, setRelativeSize)

상속받은 다양한 메서드를 직접 호출할 수 있다.

Monster m = new Monster();  // 생성자는 내부적으로 좌표, 높이, 너비, 기본 각도를 설정한다
m.rotateBy(180);        // Rotataable의 rotateBy 호출
m.moveVertically(10);   // Moveable의 moveVertically 호출

이번에는 움직일 수 있으며 회전할 수 있지만, 크기를 조절할 수 없는 Sun 클래스를 정의한다.

public class Sun implements Moveable, Rotatable {
    ...
}

인터페이스에 디폴트 구현을 포함시키면 또 다른 장점이 생긴다. 예를 들어 moveVertically의 구현을 더 효율적으로 고쳐야 한다고 가정하자. 디폴트 메서드 덕분에 Moveable 인터페이스를 직접 고칠 수 있고 따라서 Moveable을 구현하는 모든 클래스도 자동으로 변경한 코드를 상속받는다(물론 구현 클래스에서 메서드를 정의하지 않은 상황에 한해서다)

13.4 해석 규칙

같은 시그니처를 갖는 디폴트 메서드를 다중 상속 받는 상황에서 어떤 인터페이스의 디폴트 메서드를 사용하게 될 것인가?

public interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

public interface B extends A {
    default void hello() {
        System.out.println("Hello from B");
    }
}

public class C implements B, A {
    public static void main(String... args) {
        new C().hello();  // 무엇이 출력될까?
    }
}

13.4.1 알아야 할 세 가지 해결 규칙

다른 클래스나 인터페이스로부터 같은 시그니처를 갖는 메서드를 상속받을 때는 세 가지 규칙을 따라야 한다.

1. 클래스가 항상 이긴다. 클래스나 슈퍼클래스에서 정의한 메서드가 디폴트 메서드보다 우선권을 갖는다.

2. 1번 규칙 이외의 상황에서는 서브인터페이스가 이긴다. 상속관계를 갖는 인터페이스에서 같은 시그니처를 갖는 메서드를 정의할 때는 서브인터페이스가 이긴다.

   → 즉, B가 A를 상속받는다면 B가 A를 이긴다.

3. 여전히 디폴트 메서드의 우선순위가 결정되지 않았다면 여러 인터페이스를 상속받는 클래스가 명시적으로 디폴트 메서드를 오버라이드하고 호출해야 한다.

13.4.2 디폴트 메서드를 제공하는 서브인터페이스가 이긴다

B와 A는 hello라는 디폴트 메서드를 정의한다. 또한 B는 A를 상속받는다.

2의 규칙에 따라 B의 hello를 선택한다. 즉, ‘Hello from B’를 추력한다.

다음처럼 C가 D를 상속받는다면 어떻게 될지 보자

public class D implements A {  }
public class C extends D implements B, A {
    public static void main(String... args) {
        new C().hello(); // 무엇이 출력될까?
    }
}

1번 규칙은 클래스의 메서드 구현이 긴다고 설명한다. D는 hello를 오버라이드 하지 않았고 단순히 인터페이스 A를 구현했다. 따라서 D는 인터페이스 A의 디폴트 메서드 구현을 상속받는다.

2번 규칙에서는 클래스나 슈퍼클래스에 메서드 정의가 없을 때는 디폴트 메서드를 정의하는 서브 인터페이스가 선택된다. 따라서 컴파일러는 인터페이스 A의 hello나 인터페이스 B의 hello 둘 중 하나를 선택해야 한다. 여기서 B가 A를 상속받는 관계이므로 이번에도 ‘Hello from B’가 출력된다.

• Quiz. 해석 규칙을 기억하라

  프로그램의 실행 결과는 무엇인가?

    public class D implements A {
        void hello() {
            System.out.println("Hello from D");
        }
    }
      
    public class C extends D implements B, A {
        public static void main(String... args) {
            new C().hello();
        }
    }
  

  • 정답

    실행 결과는 ‘Hello from D’이다. 규칙 1에 의해 슈퍼클래스의 메서드 정의가 우선권을 갖기 때문이다.

    D가 다음처럼 구현되었다고 가정하자.

      public abstract class D implements A {
          public abstract void hello();
      }
    

    그러면 A에서 디폴트 메서드를 제공함에도 불구하고 C는 hello를 구현해야 한다.

13.4.3 충돌 그리고 명시적인 문제 해결

이번에는 B가 A를 상속받지 않는 상황이다.

public interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

public interface B {
    default void hello() {
        System.out.println("Hello from B");
    }
}

public class C implements B, A {  }

이번에는 인터페이스간 상속 관계가 없으므로 2번 규칙을 적용할 수 없다. 그러므로 A와 B의 hello 메서드를 구별할 기준이 없다.

따라서 자바 컴파일러는 어떤 메서드를 호출해야 할지 알 수 없으므로 “Error: class C inherits unrelated defaults for hello() from types B and A” 같은 에러가 발생한다.

충돌 해결

클래스와 메서드 관계로 디폴트 메서드를 선택할 수 없는 상황에서 선택할 수 있는 방법이 없다.

⇒ 클래스 C에서 hello 메서드를 오버라이드한 다음에 호출하려는 메서드를 명시적으로 선택해야 한다.

자바 8에서는 X.super.m(…) 형태의 새로운 문법을 제공한다. 여기서 X는 호출하려는 메서드 m의 슈퍼 인터페이스다. 예를 들어 다음처럼 C에서 B의 인터페이스를 호출할 수 있다.

public class C implements B, A {
    void hello() {
        B.super.hello(); // 명시적으로 인터페이스 B의 메서드 선택
    }
}

• Quiz. 거의 비슷한 시그니처

  인터페이스 A와 B가 다음처럼 정의되어 있다고 가정하자

    public interface A {
        default Number getNumber() {
            return 10;
        }
    }
      
    public interface B {
        default Integer getNumber() {
            return 42;
        }
    }
      
    public class C implements B, A {
        public static void main(String... args) {
            System.out.println(new C().getNumber()));
        }
    }
  

  프로그램 출력 결과는?

  • 정답

    C는 A와 B 메서드를 구분할 수 없다. 따라서 클래스 C에서 컴파일 에러가 발생한다.

13.4.4 다이아몬드 문제

public interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}
public interface B extends A { }
public interface C extends A { }
public class D implements B, C {
    public static void main(String... args) {
        new D().hello();  // 무엇이 출력될까?
    }
}

해당 시나리오는 다이아몬드 문제라고 부른다. D는 B와 C 중 누구의 디폴트 메서드 정의를 상속받을까? 실제로 선택할 수 있는 메서드 선언은 하나뿐이다. A만 디폴트 메서드를 정의하고 있다. 결국 프로그램 출력 결과는 ‘Hello from A’가 된다.

B와 C 모두 디폴트 메서드 hello 메서드를 정의한다면 충돌이 발생하므로 둘 중 하나의 메서드를 명시적으로 호출해야 한다.

다음처럼 인터페이스 C에 추상 메서드 hello(디폴트 메서드 아님!)를 추가하면 어떤일이 발생할까(A와 B에는 아무 메서드도 정의하지 않는다)?

public interface C extends A {
    void hello();
}

C는 A를 상속받으므로 C의 추상 메서드 hello가 A의 디폴트 메서드 hello보다 우선권을 갖는다. 따라서 컴파일 에러가 발생하며, 클래스 D가 어떤 hello를 사용할지 명시적으로 선택하여 에러를 해결해야 한다.