아이템 20. 추상 클래스보다는 인터페이스를 우선하라. - ksw6169/effective-java GitHub Wiki
- 자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스 두 가지다.
- 둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.
- 반면에 인터페이스가 선언한 메소드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.
- 인터페이스가 요구하는 메소드를 추가하고, implements 만 추가하면 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다.
- ex. AutoCloseable 등의 인터페이스가 추가되었을 때 자바 표준 라이브러리의 수많은 기존 클래스가 이 인터페이스들을 구현한 채 릴리즈됐다.
- 반면에 기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운 게 일반적이다. 두 클래스가 같은 추상 클래스를 확장하길 원한다면, 그 추상 클래스는 계층구조상 두 클래스의 공통 조상이어야 한다. 안타깝게도 이 방식은 클래스 계층 구조에 커다란 혼란을 일으키는데, 새로 추가된 추상 클래스의 모든 자손이 이를 상속하게 되는 것이다. (그렇게 하는 것이 적절하지 않은 상황에서도 강제로 말이다.)
- 믹스인이란 클래스가 구현할 수 있는 타입으로 믹스인을 구현한 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
- ex. Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스다.
- 이처럼 대상 타입의 주된 기능에 선택적 기능을 '혼합(mixed in)' 한다고 해서 믹스인이라 부른다.
- 추상 클래스로는 믹스인을 정의할 수 없다. 기존 클래스에 두 부모를 추가할 수 없고, 클래스 계층 구조에는 믹스인을 삽입하기에 합리적인 위치가 없기 때문이다.
- 타입을 계층적으로 정의하면 수 많은 개념을 구조적으로 잘 표현할 수 있지만, 현실에서는 계층을 엄격히 구분하기 어려운 개념도 있다.
- 다음 예시처럼 가수와 작곡가 인터페이스가 있다고 했을 때 타입을 인터페이스로 정의하면 가수 클래스가 이 둘을 모두 구현해도 전혀 문제되지 않는다.
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) 이라 부르는 현상이다.
- 거대한 클래스 계층 구조에는 공통 기능을 정의해놓은 타입이 없으니 자칫 매개변수 타입만 다른 메소드들을 수없이 많이 가진 거대한 클래스를 낳을 수 있다.
- 타입을 추상 클래스로 정의해두면 그 타입에 기능을 추가하는 방법은 상속 뿐이다.
- 상속해서 만든 클래스는 래퍼 클래스보다 활용도가 떨어지고 깨지기는 더 쉽다.
- 구현 방법이 명백한 메소드는 디폴트 메소드로 제공해 프로그래머의 일감을 덜어줄 수 있다.
- 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;
}
};
}
- 만약 구조상 골격 구현을 확장하지 못하는 처지라면 인터페이스를 직접 구현해야 한다.
- 골격 구현 클래스를 우회적으로 이용할 수도 있다.
- 인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 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();
}
...
}
- 단순 구현은 인터페이스를 구현한 클래스로 골격 구현의 작은 변종이다. (= 골격을 완전히 구현해놓은 클래스)
- 이러한 단순 구현은 그대로 써도 되고 필요에 맞게 확장해도 된다.
// 인터페이스를 단순 구현해 기능을 모두 정의해놓았다.
public static class SimpleEntry<K,V>
implements Entry<K,V>, java.io.Serializable {
...
}
- Effective Java 3/E