아이템 20. 추상 클래스보다는 인터페이스를 우선하라. - ksw6169/effective-java GitHub Wiki

추상 클래스를 상속한 클래스는 반드시 하위 클래스가 되어야 한다.

  • 자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스 두 가지다.
  • 둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.
  • 반면에 인터페이스가 선언한 메소드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.

추상 클래스보다 인터페이스를 사용했을 때의 장점

1. 인터페이스는 기존 클래스에 손쉽게 구현(추가)할 수 있다.

  • 인터페이스가 요구하는 메소드를 추가하고, implements 만 추가하면 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다.
  • ex. AutoCloseable 등의 인터페이스가 추가되었을 때 자바 표준 라이브러리의 수많은 기존 클래스가 이 인터페이스들을 구현한 채 릴리즈됐다.
  • 반면에 기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운 게 일반적이다. 두 클래스가 같은 추상 클래스를 확장하길 원한다면, 그 추상 클래스는 계층구조상 두 클래스의 공통 조상이어야 한다. 안타깝게도 이 방식은 클래스 계층 구조에 커다란 혼란을 일으키는데, 새로 추가된 추상 클래스의 모든 자손이 이를 상속하게 되는 것이다. (그렇게 하는 것이 적절하지 않은 상황에서도 강제로 말이다.)

2. 인터페이스는 믹스인(mixin) 정의에 안성맞춤이다.

  • 믹스인이란 클래스가 구현할 수 있는 타입으로 믹스인을 구현한 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
  • ex. Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스다.
  • 이처럼 대상 타입의 주된 기능에 선택적 기능을 '혼합(mixed in)' 한다고 해서 믹스인이라 부른다.
  • 추상 클래스로는 믹스인을 정의할 수 없다. 기존 클래스에 두 부모를 추가할 수 없고, 클래스 계층 구조에는 믹스인을 삽입하기에 합리적인 위치가 없기 때문이다.

3. 인터페이스로는 계층 구조가 없는 타입 프레임워크를 만들 수 있다.

  • 타입을 계층적으로 정의하면 수 많은 개념을 구조적으로 잘 표현할 수 있지만, 현실에서는 계층을 엄격히 구분하기 어려운 개념도 있다.
  • 다음 예시처럼 가수와 작곡가 인터페이스가 있다고 했을 때 타입을 인터페이스로 정의하면 가수 클래스가 이 둘을 모두 구현해도 전혀 문제되지 않는다.
public interface Singer {
    AudioClip sing(Song s);
}

public interface Songwriter {
    Song compose(int chartPosition);
}
  • 심지어 이 둘을 모두 확장하고 새로운 메소드까지 추가한 제3의 인터페이스를 정의할 수도 있다.
public interface SingerSongwriter extends Singer, Songwriter {
    AudioClip strum();
    void actSensitive();
}
  • 같은 구조를 클래스로 만들려면 가능한 조합 전부를 각각의 클래스로 정의한 고도비만 계층 구조가 만들어질 것이다. 속성이 n개라면 지원해야 할 조합의 수는 2^n개나 된다. 흔히 조합 폭발(combination explosion) 이라 부르는 현상이다.
  • 거대한 클래스 계층 구조에는 공통 기능을 정의해놓은 타입이 없으니 자칫 매개변수 타입만 다른 메소드들을 수없이 많이 가진 거대한 클래스를 낳을 수 있다.

4. 래퍼클래스 관용구와 함께 사용하면 인터페이스는 기능을 향상시키는 안전하고 강력한 수단이 된다.

  • 타입을 추상 클래스로 정의해두면 그 타입에 기능을 추가하는 방법은 상속 뿐이다.
  • 상속해서 만든 클래스는 래퍼 클래스보다 활용도가 떨어지고 깨지기는 더 쉽다.

5. 디폴트 메소드를 제공해 프로그래머의 일감을 덜어줄 수 있다.

  • 구현 방법이 명백한 메소드는 디폴트 메소드로 제공해 프로그래머의 일감을 덜어줄 수 있다.
  • Collection 클래스에는 default 메소드로 removeIf 를 제공하는데, 디폴트 메소드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec 태그를 붙여 문서화해야 한다.
/**
 * ...
 *
 * @implSpec
 * 이 default 메소드는 컬렉션의 iterator를 사용하여 컬렉션의 모든 요소를 순회합니다. 
 * 일치하는 각 요소는 Iterator의 remove() 메소드를 사용하여 제거됩니다.
 * Collection의 iterator가 반복자를 지원하지 않는 경우 
 * 일치하는 첫 번째 요소에서 UnsupportedOperationException이 발생합니다.
 *
 * ...
 */
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;
}

추상 클래스보다 인터페이스를 사용했을 때의 단점(제약)

  • 인터페이스는 Object의 equals와 hashCode 같은 메소드들은 디폴트로 제공하면 안된다.
  • 인스턴스 필드 혹은 public이 아닌 정적 멤버를 가질 수 없다. (private 정적 메소드는 예외다.)
  • 내가 만들지 않은 인터페이스에는 디폴트 메소드를 추가할 수 없다.

인터페이스와 추상 클래스의 장점을 모두 취하는 방법

  • 인터페이스와 추상 골격 구현(skeletal implementation) 클래스를 함께 제공하여 둘의 장점을 모두 취하는 방법도 있다.
  • 즉, 개발자가 필요에 따라 둘 중 하나를 선택하여 사용하거나, 복합적으로 사용할 수 있도록 방법을 제공하는 것이다.
  • 여기서 관례상 인터페이스 이름이 Interface라면 골격 구현 클래스의 이름은 AbstractInterface로 짓는다.
  • 예를 들어 인터페이스는 List, 추상 골격 구현 클래스로는 AbstractList를 제공할 수 있다.
  • ex. 컬렉션 프레임워크의 AbstractCollection, AbstractSet, AbstractList, AbstractMap은 컬렉션 인터페이스의 골격 구현이다.
public interface List<E> extends Collection<E> { ... }
public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> { ... }
  • 인터페이스로는 타입을 정의하고, 필요하면 디폴트 메소드 몇 개도 함께 제공한다. 그리고 골격 구현 클래스는 나머지 메소드들까지 모두 구현한다. 이렇게 해두면 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다. (=템플릿 메소드 패턴)
  • 다음 코드는 완벽히 동작하는 List 구현체를 반환하는 정적 팩토리 메소드로 AbstractList 골격 구현을 활용했다.
/**
 * 골격 구현을 사용해 완성한 구체 클래스
 */
static List<Integer> intArrayAsList(int[] a) {
    Objects.requireNonNull(a);
		
    /*
       추상 골격 구현 클래스를 구현해 반환한다.  
       (abstract class를 상속한 클래스의 객체를 반환하는 효과)
       오토박싱, 오토언박싱으로 인해 성능이 좋지는 않다.
    */
    return new AbstractList<Integer>() {
        @Override
        public Integer get(int index) {
            return a[index];    // 오토박싱
        }

        @Override
        public Integer set(int index, Integer val) {
            int oldVal = a[index];
            a[index] = val;     // 오토언박싱
            return oldVal;      // 오토박싱
        }

        @Override
        public int size() {
            return a.length;
        }
    };
}
  • 만약 구조상 골격 구현을 확장하지 못하는 처지라면 인터페이스를 직접 구현해야 한다.

시뮬레이트한 다중 상속(simulated multiple inheritance)

  • 골격 구현 클래스를 우회적으로 이용할 수도 있다.
  • 인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고 각 메소드 호출을 내부 클래스의 인스턴스에 전달하는 것이다.
  • 래퍼 클래스와 비슷한 이 방식을 시뮬레이트한 다중 상속(simulated multiple inheritance) 이라 하며, 다중 상속의 많은 장점을 제공하는 동시에 단점을 피하게 해준다.
public class ImplementationList implements List {
    private InnerList innerList = new InnerList();
  
    // 골격 구현을 확장한 내부 클래스 
    private class InnerList extends AbstractList {
        @Override
        public Object set(int index, Object element) {
            ...
        }

        @Override
        public Object get(int index) {
            ...
        }

        @Override
        public int size() {
            ...
        }
    }
   
    // 내부 클래스의 인스턴스 메소드 호출
    @Override
    public Object set(int index, Object element) {
        return innerList.set(index, element);
    }

    @Override
    public Object get(int index) {
        return innerList.get(index);
    }

    @Override
    public int size() {
        return innerList.size();
    }

    ...
}

시뮬레이트한 다중 상속

직접 상속하는 대신 내부 클래스가 상속하도록 만들기 때문에 다중 상속과 같은 효과를 발생시킨다.


골격 구현 클래스 작성법

1. 인터페이스를 잘 살펴 다른 메소드들의 구현에 사용되는 기반 메소드들을 선정한다. 
   여기서 이 기반 메소드들은 골격 구현에서는 추상 메소드가 될 것이다.

* '기반 메소드 = 추상 메소드' 가 아님에 주의하자. 
  기반 메소드는 '다른 메소드들의 구현에 사용되는 메소드' 를 말한다.

2. 기반 메소드들을 사용해 직정 구현할 수 있는 메소드를 모두 디폴트로 제공한다.

3. 기반 메소드나 디폴트 메소드로 만들지 못한 메소드가 남아 있다면 이 인터페이스를 구현하는
   골격 구현 클래스를 만들어 남은 메소드들을 작성해 넣는다.
   골격 구현 클래스는 필요하면 public이 아닌 필드와 메소드를 추가해도 된다.

* 만약 인터페이스의 메소드 모두가 기반 메소드와 디폴트 메소드로 구성된다면 골격 구현 클래스를
  별도로 만들 이유는 없다.
  • 예시로 Map.Entry 인터페이스를 살펴보자. 여기서 getKey, getValue는 기반 메소드이며, 선택적으로 setValue도 포함될 수 있다.
public abstract class AbstractMapEntry<K,V> implements Map.Entry<K,V> {

    // 변경 가능한 엔트리는 이 메소드를 반드시 재정의해야 한다.
    @Override
    public V setValue(V value) {
        throw new UnsupportedOperationException();
    }

    ...
}

단순 구현(simple implementation)

  • 단순 구현은 인터페이스를 구현한 클래스로 골격 구현의 작은 변종이다. (= 골격을 완전히 구현해놓은 클래스)
  • 이러한 단순 구현은 그대로 써도 되고 필요에 맞게 확장해도 된다.
// 인터페이스를 단순 구현해 기능을 모두 정의해놓았다.
public static class SimpleEntry<K,V> 
        implements Entry<K,V>, java.io.Serializable {
    ...
}

참고 자료

  • Effective Java 3/E
⚠️ **GitHub.com Fallback** ⚠️