[Effective Java] 아이템 20 : 추상 클래스보다는 인터페이스를 우선하라

Loopy·2022년 7월 8일

Java

이펙티브 자바

목록 보기

19/76

자바는 인터페이스와 추상 클래스 두가지를 통해 다중 구현 메커니즘 을 제공한다.

추상 클래스 단점

하지만, 자바는 단일 상속만 가능하므로 추상 클래스를 사용하면 새로운 타입을 정의하는데 제약이 존재한다. 즉, 추상 클래스가 정의한 타입을 구현한 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다.

반면 인터페이스가 선언한 메서드를 모두 정의하고 일반 규약을 잘 지킨 클래스라면, 다른 어떤 클래스를 상속했든 같은 타입으로 취급된다.

☁️ 인터페이스의 장점

1. 기존 클래스에 손쉽게 새로운 인터페이스를 구현해 넣을 수 있다.

기존 클래스 위에 새로운 추상 클래스를 끼워넣기는 어려운 것이, 두 클래스가 같은 추상 클래스를 확장하길 원한다면 그 추상 클래스는 두 클래스의 공통 조상이어야 하기 때문이다. 반면 인터페이스는 요구하는 메서드를 추가하고, 클래스 선언에 implements 구문만 추가하면 끝이다.

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

📚 Mixin?

대상 타입의 주된 기능에 선택적 기능을 혼합(mixed in) 한다는 의미

객체지향언어에서 다른 클래스에서 사용할 목적으로 만들어진 클래스

믹스인을 구현할 클래스에 원래의 '주된 타입' 외에도 특정 선택적 행위를 제공할 수 있다.

예를 들어, Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스이다. (참고로 다중 상속이 안되기 때문에 추상 클래스로는 믹스인을 정의 불가능하다)

이처럼, 인터페이스로는 계층 구조가 없는 타입 프레임워크를 만들 수 있다. 현실에서 계층을 엄격하게 구분하게 어려운 경우의 예시를 들어보자.

public interface Singer {
  AudioClip sing(Song s);
}

public interface Songwriter {
  Song compose(int chartPosition);
}

작곡과 가수를 동시에 하는 사람을 위해, 아래와 같이 믹스인 인터페이스로 정의 가능하다.

public interface SingerSongwriter extends Singer, Songwriter {
  AudioClip strum();   //새로운 메서드 추가
  void actSensitive();
}

같은 구조를 클래스로 만들면, 클래스에는 공통 기능을 정의해놓는 타입이 없으니 가능한 2^n개의 조합(속성이 n 개일때) 전부를 클래스로 정의한 고도비만 계층 구조가 만들어질 것이다. 흔히, 이러한 현상을 조합 폭발이라 부른다.

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

타입을 추상 클래스로 정의해두면, 그 타입에 기능을 추가하는 방법은 상속 밖에 없어진다.

인터페이스 메서드 중 구현 방법이 명백한 것이 있다면, 디폴드 메서드로 제공하자. 단, 상속하려는 사람을 위한 설명을 @implSpec 자바독 태그를 붙여 문서화 해야한다. (아이템 19)

📚 디폴트 메서드 제약
1) equals와 hashCode같은 Object메서드는 디폴트 메서드로 제공해서는 안된다.
2) 인터페이스는 인스턴스 필드를 가질 수 없고 public 이 아닌 정적 멤버도 가질 수 없다.(private 정적 메서드 제외)
3) 직접 만들지 않은 인터페이스에는 디폴드 메서드를 추가할 수 없다.

☁️ 인터페이스와 추상 골격 클래스

한편, 인터페이스와 추상 골격 클래스(skeletal implementation)를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 존재한다.

인터페이스로는 타입을 정의와 필요한 디폴트 메서드를 제공한다.
골격 구현 클래스로 나머지 메서드들까지 구현한다.

이렇게 되면 단순히 골격 구현을 확장하는 것만으로 인터페이스를 구현하는데 필요한 일이 완료된다. 다른 말로 템플릿 메서드 패턴(Template Method Pattern)이라고 하는데, 구조는 다음과 같다.

interface InterfaceA {
    void methodA();
}

abstract class AbstractClassA implements InterfaceA {
    abstract void methodB();
}

class ConcreteClassA extends AbstractClassA {
    public void methodA() {
        System.out.println("method A");
    }

    public void methodB() {
        System.out.println("method B");
    }
}

🔗 템플릿 패턴

템플릿 메서드 패턴이란, 전체 알고리즘 중 변하는 부분만 추상 메서드로 정의하여 서브 클래스에서 자유롭게 상속받아 구현할 수 있도록 하는 패턴이다. 하나의 골격을 정의한다고 생각해도 좋다.

인터페이스의 이름 앞에 Abstract 를 붙여서 골격 구현 클래스를 생성한다.

컬렉션 프레임워크의 AbstractCollection, AbtractSet, AbstractList, AbstractMap 은 각각이 핵심 컬렉션 인터페이스의 골격 구현이다.


public abstract class AbstractCollection<E> implements Collection<E> {

    public abstract Iterator<E> iterator();
    public abstract int size();
}

public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> {

    protected AbstractList() {}
    
    public abstract E get(int index);
}

골격 구현을 사용해 완성한 구체 클래스

public class IntArrays {
    static List<Integer> intArrayAsList(int[] a) {
        Objects.requireNonNull(a);
        
        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;
            }
        };
    }
}

골격 구현 클래스는 추상 클래스처럼 구현을 도와주는 동시에, 추상 클래스로 타입을 정의할때 오는 심각한 제약에서 자유롭다. 인터페이스는 무제한으로 구현할 수 있기 때문이다.

🔗 골격 구현 작성 방법

인터페이스를 살펴 다른 메서드들의 구현에 사용되는 기반 메서드를 선정한다.
기반 메서드들을 사용해 직접 구현할 수 있는 메서드들은 모두 디폴트로 제공한다. equals(), hasCode()와 같은 Object 메서드는 제외한다.
기반 메서드나 디폴트 메서드로 만들지 못한 메서드가 남아 있다면, 인터페이스를 구현하는 골격 구현 클래스를 만들어 집어넣는다. (필요하면 public 이 아닌 필드와 메서드 추가 가능)

public abstract class AbstractMapEntry<K,V>
        implements Map.Entry<K,V> {
        
    // 변경 가능한 엔트리는 이 메서드를 반드시 재정의해야 한다.
    @Override public V setValue(V value) {
        throw new UnsupportedOperationException();
    }
    
    @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());
    }

    @Override public int hashCode() {
        return Objects.hashCode(getKey())
                ^ Objects.hashCode(getValue());
    }

    @Override public String toString() {
        return getKey() + "=" + getValue();
    }
}

Object 메서드들은 디폴트 메서드로 제공해서는 안되므로, toString() 과 함께 모두 골격 구현 클래스에 구현해놓았다.

참고로 골격 구현은 기본적으로 상속해서 사용하는 걸 가정하므로, 아이템 19에서 이야기한 설계 및 문서화 지침을 모두 따라야 한다.

📚 핵심 정리
일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다. 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법도 고려해보자. 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다. '가능한 한'이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.

공통으로 사용되는 기능을 정의하려면 인터페이스 default 보다는 추상 클래스를 활용해라.