상속

자식 클래스를 이용해 부모 클래스의 코드 재사용
컴파일 타임에 의존성 해결
is-a 관계
부모 클래스와 다른 부분만 추가하거나 재정의함으로써 기존 코드를 쉽게 확장
부모 클래스 내부 구현에 대해 상세하게 알아야 하기 때문에 결합도가 높아짐
클래스 간 정적 관계: 코드 작성 시점에 결정한 관계, 변경 불가

합성

부분을 표현하는 객체를 포함해서 코드 재사용
런타임에 의존성 해결
has-a 관계
내부에 포함된 객체의 구현이 아닌 퍼블릭 인터페이스에 의존
객체의 내부 구현이 변경되더라도 영향을 최소화할 수 있음
객체 간 동적 관계: 실행 시점에 동적으로 변경 가능

<aside> 💡

코드 재사용을 위해서는 객체 합성이 클래스 상속보다 더 좋은 방법이다

</aside>

1. 상속을 합성으로 변경하기

불필요한 인터페이스 상속 문제

자식 클래스에게는 부적합한 부모 클래스의 오퍼레이션 상속
자식 클래스 인스턴스의 상태가 불안정

메서드 오버라이딩의 오작용 문제

부모 클래스의 메서드를 오버라이딩할 때 자식 클래스가 부모 클래스의 메서드 호출 방법에 영향

부모 클래스와 자식 클래스의 동시 수정 문제

부모 - 자식 간 개념적 결합으로 인해 부모 클래스를 변경할 때 자식 클래스도 함께 변경
상속을 합성으로 바꾸는 방법: 자식 클래스에 선언된 상속 관계를 제거하고 부모 클래스의 인스턴스를 자식 클래스의 인스턴스 변수로 선언

1. 불필요한 인터페이스 상속 문제

public class Properties {
	private Hashtable<String, String> properties = new Hashtable<>();
	
	public String setProperty(String key, String value) {
		return properties.put(key, value);
	}
	
	public String getProperty(String key) {
		return properties.get(key)；
	}
}

Properties가 Hashtable을 상속받지 않고 인스턴스 변수로 포함시킴
불필요한 Hashtable 오퍼레이션들이 Properties의 인터페이스를 오염시키지 않음
클라이언트는 오직 String 타입 key와 value만 허용
Properties는 Hashtable의 내부 구현을 알지 못함

public class Stack<E> {
	private Vector<E> elements = new Vector<>();
	
	public E push(E item) {
		elements.addElement(item);
		return item;
	}
	
	public E pop() {
		if (elements.isEmpty()) {
			throw new EmptyStackException();
		}
		
		return elements.remove(elements.size() - 1);
	}
}

합성 관계로 변경함으로서 Stack의 퍼블릭 인터페이스에는 불필요한 Vector의 오퍼레이션들이 포함되지 않음
클라이언트는 더 이상 임의의 위치에 요소를 추가하거나 삭제할 수 없음

2. 메서드 오버라이딩의 오작용 문제

public class InstrumentedHashSet<E> : implements Set<E> {
	private int addCount = 0;
	private Set<E> set;
	
	public InstrumentedHashSet(Set<E> set) {
		this.set = set;
	}
	
	@Override
	public boolean add(E e) {
		addCount++;
		return set.add(e);
	}
	
	@Override
	public boolean addAll(Collection<? extends E> c) {
		addCount += c.size();
		return set.addAll(c);
	}
	
	public int getAddCount() {
		return addCount;
	}
	
	©Override public boolean remove(Object o) { return set.remove(o); }
	©Override public void clear() { set.clear(); }
	©Override public boolean equals(Object o) { return set.equals(o); }
	©Override public int hashCode() { return set.hashCode(); }
	©Override public Spliterator<E> spliterator() { return set.spliterator(); }
	©Override public int size() { return set.size(); }
	©Override public boolean isEmpty() { return set.isEmpty(); }
	©Override public boolean contains(Object o) { return set.contains(o)； }
	©Override public Iterator<E> iterator() { return set.iterator(); }
	©Override public Object[] toArray() { return set.toArray(); }
	©Override public <T> T[] toArray(T[] a) { return set.toArray(a); }
	©Override public boolean containsAll(Collection<?> c) { return set.containsAll(c); }
	©Override public boolean retainAll(Collection<?> c) { return set.retainAll(c); }
	©Override public boolean removeAll(Collection<?> c) { return set.removeAll(c); }
}

InstrumentedHashSet은 HashSet이 제공하는 퍼블릭 인터페이스를 그대로 제공해야 함
따라서 퍼블릭 인터페이스만 상속받기 위해 Set 인터페이스를 실체화하도록 수정
Set 오퍼레이션을 오버라이딩한 메서드들은 HashSet 인스턴스에게 동일한 메서드 호출을 그대로 전달: forwarding

3. 부모 클래스와 자식 클래스의 동시 수정 문제

class PersonalPlaylist
{
public:
	PersonalPlaylist()
		: playlist(nullptr)
	{
		playlist = new Playlist();
	}

	~PersonalPlaylist() {}

	void Emplace(const Song& song) const
	{
		playlist->Emplace(song);
	}

	void Erase(const Song& song) const
	{
		std::erase(playlist->GetTracks(), song);
		playlist->GetSingers().erase(song.GetSinger());
	}

private:
	Playlist* playlist;
};

합성으로 변경하더라도 가수별 노래 목록을 유지하기 위해 여전히 Playlist도 함께 수정해야 함
그럼에도, 향후 Playlist의 내부 구현을 변경하더라도 파급효과를 최대한 PersonalPlaylist 내부로 캡슐화할 수 있기 때문에 합성을 사용하는 것이 좋음

2. 상속으로 인한 조합의 폭발적인 증가

보통 작은 기능들을 조합해서 더 큰 기능을 수행해야 하는 객체를 만들 때, 상속 구조로 설계하면 결합도가 높아져 코드 수정에 필요한 작업량이 과도하게 늘어나는 경향이 있음
- 하나의 기능을 추가하거나 수정하기 위해 불필요하게 많은 수의 클래스를 추가하거나 수정
- 단일 상속만 지원하는 언어에서는 상속으로 인해 오히려 중복 코드의 양이 늘어날 수 있음

1. 기본 정책과 부가 정책 조합하기

핸드폰 과금 시스템에 “부가 정책” 추가
기본 정책: 가입자의 통화 정보 기반
- 가입자의 한달 통화량을 기준으로 부과할 요금 계산
- ‘일반 요금제’, ‘심야 할인 요금제’가 여기에 해당
부가 정책: 통화량과 무관하게 선택적으로 추가할 수 있는 요금 방식
- 세금 정책이 여기에 해당
- 이외에 최종 계산된 요금에서 일정 금액을 할인해주는 ‘기본 요금 할인 정책’ 존재

기본 정책의 계산 결과에 적용된다

세금 정책은 기본 정책 계산이 끝난 결과에 부과

선택적으로 적용할 수 있다

세금 정책을 적용할 수도, 안할 수도 있음

조합 가능하다

세금 정책만 적용하거나, 기본 요금 할인 정책만 적용하거나, 둘 다 적용 가능

부가 정책은 임의의 순서로 적용 가능하다