[Effective Java] 클래스와 인터페이스 中

18. 상속보다는 컴포지션 사용

다른 패키지의 구체 클래스를 상속하는 일은 위험

 

• 메서드 호출과 달리 상속은 캡슐화를 깨뜨림 👉 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상 생길 수 있음
• 상위 클래스는 릴리즈마다 내부 구현이 달라질 수 있는데, 그로 인해 하위 클래스가 오동작할 수 있음 

✳️ 상속을 잘못 사용한 예 

public class InstrumentedHashSet<E> extends HashSet<E> {
    
    private int addCount = 0;
    
    public InstrumentedHashSet(){
     
    }
    
    public InstrumentedHashSet(int initCap, float loadFactor){
        super(initCap, loadFactor);
    }
    
    @Override
    public boolean add(E e){
        addCount ++;
        return super.add(e);
    }
    
    @Override
    public boolean addAll(Collection<? extends E> c){
        addCount += c.size();
        return super.addAll(c);
    }
    
    public int getAddCount(){
        return getAddCount();
    }
}

InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(List.of("틱", "탁탁", "펑"));

위와 같은 코드에서 addAll 메서드로 원소 3개를 더했다고 했을 때, 결과는 3이 아닌 6을 반환한다.

HashSet의 addAll 메서드가 각 원소를 add 메서드를 호출해 추가하는데, 이때 불리는 add 메서드는 InstrumentedHashSet에서 재정의한 메서드다. 그러므로 addCount에 값이 중복해서 더해져 6을 반환하는 것이다. 

 

이외에도 메서드를 재정의하는 대신 상위 클래스에 새로운 메서드를 추가해 재정의와 관련된 문제를 해결할 수 있는 방법을 생각할 수도 있다. 하지만 이 메서드가 우연히도 하위클래스에 추가한 메서드와 시그니처가 같고 반환 타입은 다르다면 해당 클래스는 컴파일 조차 되지 않을 수 있다. 혹여나 반환 타입이 같다면 상위 클래스의 새 메서드를 재정의한 것이니 재정의와 관련된 문제가 또 다시 발생할 수 있다.

---

✳️ 컴포지션 

 

위와 같은 상속과 관련된 문제를 해결할 수 있는 방법은 '컴포지션' 이다.

기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하면 된다. 

기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 뜻에서 컴포지션(구성)이라 하는 것이다. 

 

새 클래스의 인스턴스 메서드들은 기존 클래스(private 필드로 참조)의 대응하는 메서드를 호출해서 그 결과를 반환한다 = 전달(Forwarding)

 

✴️ 전달 클래스 

public class ForwardingSet<E> implements Set<E>{
	private final Set<E> s; // private 필드로 기존 클래스의 인스턴스 참조 
    public ForwardingSet(Set<E> s) {this.s = s;} // Set의 인스턴스를 인수로 받는 생성자
    
    // 전달 메서드
    public void clear() { s.clear(); }
    public boolean contains(Object o) {return s.contains(o); }
    public boolean isEmpty() { return s.isEmpty(); }
    public int size() { return s.size(); }
    public Iterator<E> iterator() { return s. iterator(); }
    public boolean add(E e) { return s.add(e); }
    public boolean remove(Object o) {return s.remove(o); }
    public boolean containsAll(Collection<?> c) { return s.containsAll(c); }
    public boolean addAll(Collection<? extends E> c) { return s.addAll(c); }
    public boolean removeAll(Collection<?> c) { return s.removeAll(c); }
    public boolean retainAll(Collection<?> c) { return s.retainAll(c); }
    public Object[] toArray() { return s.toArray(); }
    public <T> T[] toArray(T[] a) { return s.toArray(a); }
    @Override public boolean equals(Object o) { return s.equals(o); }
    @Override public int hashCode() {return s.hashCode(); }
    @Override public String toString() { return s.toString(); }
}

 

✴️ 래퍼 클래스 

public class InstrumentedSet<E> extends ForwardingSet<E> {

    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override 
    public boolean addAll (Collection< ? extends E > c){
        addCount += c.size();
        return super.addAll(c); 

    }

    public int getAddCount () {
        return addCount;
    }
}

다른 Set 인스턴스를 감싸고 있다는 뜻에서 InstrumentedSet과 같은 클래스를 래퍼 클래스라고 한다 = Decorator Pattern

 

전달 메서드들을 작성하는 것이 지루하겠지만, 재사용할 수 있는 전달 클래스를 인터페이스 당 하나씩만 만들어두면 원하는 기능을 덧씌우는 전달 클래스들을 손쉽게 구현할 수 있다. 

---

그렇다면 상속은 언제 사용되는 것일까??

 

반드시 하위 클래스가 상위 클래스의 '진짜' 하위 타입인 상황에서만 사용하면 된다. 

즉, is-a 관계일 때만 상속하면 되는 것이다. 

 

 

19. 상속을 고려해 설계하고 문서화하기. 그렇지 않으면 상속 금지

상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 함

 

 

20. 추상 클래스보다는 인터페이스를 우선 !

다중 구현용 타입으로는 인터페이스가 가장 적합

 

자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스 두 가지가 있다.

 

• 인터페이스
  • 인터페이스가 선언한 메서드를 모두 정의하고 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급됨 
• 추상 클래스
  • 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 함
  • 자바는 단일 상속만 지원하므로 새로운 타입을 정의하는 데 제약이 있음 

interface Vehicle {
    void drive();
}

class Car {
    // Car만의 고유한 메서드
    public void honk() {
        System.out.println("Honk!");
    }
}

// Car를 상속받으면서 Vehicle 인터페이스도 구현
class SportsCar extends Car implements Vehicle {
    @Override
    public void drive() {
        System.out.println("Driving a sports car!");
    }
}

👉 SportsCar가 Car를 상속받았지만 그와 상관없이 Vehicle 인터페이스를 구현했기 때문에, Vehicle 타입으로 취급할 수 있음

---

✳️ 인터페이스 장점 

• 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을 수 있음
  • 인터페이스가 요구하는 메서드를 추가하고 클래스 선언에 implements 구문만 추가하면 됨
  • 만약 두 클래스가 같은 추상 클래스를 확장하길 원한다면 그 추상 클래스는 계층 구조 상 두 클래스의 공통 조상이어야 함
    👉 새로 추가된 추상 클래스의 모든 자손이 이를 상속하게 됨. 그렇게 하는 것이 적절하지 않은 상황에서도 강제로 할 수밖에 없음
• 믹스인(mixin) 정의에 안성맞춤
  • mixin : 특정 클래스가 상속 없이 다른 클래스의 기능을 재사용할 수 있도록 하는 방식
• 계층 구조가 없는 타입 프레임워크를 만들 수 있음 

public interface Singer{
	public void sing();
}

public interface SongWriter{
	public void compose();
}

public interface SingerSongWriter extends Singer, SongWriter{
	public void actSensitive();
}

Singer와 SongWriter 모두를 확장하고 새로운 메서드까지 추가한 제3의 인터페이스를 정의할 수 있음

---

✳️ 인터페이스와 추상 골격 구현 클래스 함께 사용 👉 템플릿 메서드 패턴 

• 인터페이스로는 타입 정의 + 디폴트 메서드 
• 골격 구현 클래스는 나머지 메서드까지 구현
  👉 인터페이스의 기본적인 구현을 제공하면서, 일부 메서드는 추상 메서드로 남겨두어 하위 클래스에서 구현하도록 만드는 클래스
• 관례상 인터페이스의 이름이 Interface라면 골격 구현 클래스는 AbstractInterface로 지음

public abstract class AbstractList<E> implements List<E> {
    // List 인터페이스의 일부 메서드는 미리 구현
    @Override
    public boolean add(E e) {
        add(size(), e);
        return true;
    }

    @Override
    public boolean isEmpty() {
        return size() == 0;
    }

    // 핵심 메서드는 여전히 추상 메서드로 남겨둠
    public abstract E get(int index);
    public abstract int size();
    public abstract void add(int index, E element);
}

public class MyArrayList<E> extends AbstractList<E> {
    private E[] data;
    private int size;

    public MyArrayList() {
        data = (E[]) new Object[10];
        size = 0;
    }

    @Override
    public E get(int index) {
        return data[index];
    }

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

    @Override
    public void add(int index, E element) {
        data[index] = element;
        size++;
    }
}

 

 

 

 

21. 인터페이스는 구현하는 쪽을 생각해 설계하기

• 자바 8에서 인터페이스에 디폴트 메서드가 추가됨 👉 람다 활용하기 위해서

default boolean removeIf(Predicate<? super E> filter) { 
    Objects.requireNonNull(filter); 
    boolean result = false; 
    for(Iterator<E> it = iterator(); it.hasNext(); ) { 
        if(filter.test(it.next())) { 
            it.remove(); 
            result = true; 
        } 
    } 
    return result; 
}

removeIf는 Collection 인터페이스에 추가된 디폴트 메서드이다. 

이 메서드는 모든 Collection 구현체와 잘 어우러지는 것은 아니다. 

 

아파치의 SynchronizedCollection 클래스는 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공하고 있다.

하지만 removeIf 메서드를 재정의하고 있지 않다. 즉, 모든 메서드 호출을 알아서 동기화해주지 못하는 것이다. 

removeIf의 구현은 동기화에 관해 아무것도 모르므로 락 객체를 사용할 수 없어 removeIf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다. 

 

이러한 문제를 예방하기 위해 자바에서는 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다. 

 

 

 

 

 

22.  인터페이스는 타입을 정의하는 용도로만 사용하기

클래스가 어떤 인터페이스를 구현한다 = 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는 것
상수 공개용 수단으로 사용 X

 

• 상수 인터페이스 = static final 필드로만 가득 찬 인터페이스
  • 클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당함
  • 상수 인터페이스를 구현하는 것은 내부 구현을 클래스의 API로 노출하는 행위이므로 사용자에게 혼란을 줄 수 있거나 클라이언트 코드가 내부 구현에 해당하는 이 상수들에 종속되게 함 
• 상수를 공개할 목적이라면 그 클래스나 인터페이스 자체에 추가해야 함
  • 열거 타입으로 나타내기 적합한 상수라면 열거 타입(ENUM)으로 !
  • 인스턴스화할 수 없는 유틸리티 클래스에 담아 공개하기
    👉 정의된 상수를 클라이언트에서 사용하려면 클래스 이름까지 명시해야 함 = PhysicalConstants.AVOGARDOS_NUMBER

// 상수 유틸리티 클래스
public class PhysicalConstants {
    private PhysicalConstants() {} // 인스턴스화 방지
    
    static final double AVOGADROS_NUMBER = 6.022;
    static final double BOLTZMANN_CONSTANT = 1.38;
    static final double ELECTRON_MASS = 9.109;
}