자바가 제공하는 다중 구현 메커니즘은 인터페이스
와 추상 클래스
2가지다.
두 메커니즘 모두 인스턴스 메서드를 구현 형태로 제공할 수 있다.
둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.
자바는 단일 상속만을 지원하므로, 추상 클래스 방식은 새로운 타입을 정의하는 데 커다란 제약을 안겨준다.
반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.
또한 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다. (인터페이스가 요구하는 메서드를 추가하고, 클래스 선언에 implements
구문을 추가하기만 하면 된다.)
반면 기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운게 일반적이다.
인터페이스는 믹스인
정의에 안성맞춤이다.
믹스인
이란, 클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
대상 타입의 주된 기능에 선택적 기능을 혼합(mixed in)한다고 해서 믹스인이라 부른다.
추상 클래스에서는 믹스인을 정의할 수 없다. (기존 클래스에 덧씌울 수 없기 때문)
추상 클래스에서 속성 여러 조합을 제공하려면 가능한 조합 전부를 각각의 클래스로 정의한 계층구조가 만들어질 것이다.
속성이 n개라면 지원해야 할 조합의 수는 2^n개다.
흔히 조합 폭발
(combinatiorial explosion)이라 부르는 현상이다.
자바 8부터 인터페이스도 디폴트 메서드
를 제공할 수 있게 되었다.
인터페이스의 메서드 중 구현 바법이 명백한 것이 있다면, 그 구현을 디폴트 메서드로 제공해 프로그래머들의 일감을 덜어줄 수 있다.
디폴트 메서드에도 제약은 있다.다음을 참고하자.
인터페이스와 추상 골격 구현 클래스
를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다.
인터페이스로 타입을 정의하고 필요하다면 디폴트 메서드 몇 개도 함께 제공한다.
그리고 골격 구현 클래스는 나머지 메서드들까지 구현한다.
이렇게 해두면 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다.
이것이 바로 템플릿 메서드 패턴
이다.
관례상 인터페이스 이름이 Interface라면 그 골격 구현 클래스의 이름은 AbstractInterface로 짓는다.
ex) AbstractCollection, AbstractList, AbstractMap
📍 골격 구현을 사용해 완성한 구체 클래스 예제
static List<Integer> intArrayAsList(int[] a) {
Objects.requireNonNull(a);
// 다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
// 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
return new AbstractList<>() {
@Override public Integer get(int i) {
return a[i]; // 오토박싱(아이템 6)
}
@Override public Integer set(int i, Integer val) {
int oldVal = a[i];
a[i] = val; // 오토언박싱
return oldVal; // 오토박싱
}
@Override public int size() {
return a.length;
}
};
}
골격 구현 작성은 상대적으로 쉽다.
📍 골격 구현 클래스 예시
public abstract class AbstractMapEntry<K,V>
implements Map.Entry<K,V> {
// 변경 가능한 엔트리는 이 메서드를 반드시 재정의해야 한다.
@Override public V setValue(V value) {
throw new UnsupportedOperationException();
}
// Map.Entry.equals의 일반 규약을 구현한다.
@Override public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof Map.Entry))
return false;
Map.Entry<?,?> e = (Map.Entry) o;
return Objects.equals(e.getKey(), getKey())
&& Objects.equals(e.getValue(), getValue());
}
// Map.Entry.hashCode의 일반 규약을 구현한다.
@Override public int hashCode() {
return Objects.hashCode(getKey())
^ Objects.hashCode(getValue());
}
@Override public String toString() {
return getKey() + "=" + getValue();
}
}
골격 구현은 기본적으로 상속해서 사용하는 걸 가정하므로 아이템 19에서 이야기한 설계 및 문서화 지침을 모두 따라야 한다.
예시에서는 문서화 주식을 생략했다.
단순 구현
은 골격 구현의 작은 변종으로 AbstractMap.SimpleEntry가 좋은 예다.
단순 구현도 골격 구현과 같이 상속을 위해 인터페이스를 구현한 것이지만, 추상 클래스가 아니란 점이 다르다.
단순 구현은 그대로 써도 되고 필요에 맞게 확장해도 된다.
📌 핵심 정리
- 일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다.
- 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 고려하자.
- 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다.
'가능한 한'이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.