**Composition(합성)**은 다른 객체를 보유하고("has-a" 관계) 그에게 위임하여 동작을 구성합니다. **Inheritance(상속)**는 class를 확장하여("is-a") 동작을 획득합니다. "composition을 선호하라"는 조언이 존재하는 이유는, inheritance가 기반 class와 강하고 깨지기 쉬운 결합을 만드는 반면 composition은 유연하게 유지되기 때문입니다.
<T> <T> {
{ add(x); }
T { remove(size() - ); }
}
class Stack<T> {
private final List<T> items = new ArrayList<>(); // 리스트를 HAS-A
void push(T x) { items.add(x); }
T pop() { return items.remove(items.size() - 1); }
// push/pop 만 노출됨 → LIFO 불변식이 안전
}
리스트이는 것이 아니라 리스트를 보유함으로써, Stack은 원하는 연산만 노출합니다.
| Composition | Inheritance |
|---|---|
| 유연함, 런타임에 부품 교체 | 컴파일 타임에 고정 |
| 내부를 숨김 (위임) | 전체 인터페이스를 상속 |
| 더 많은 연결/보일러플레이트 | 진정한 is-a일 때 코드가 적음 |
| 깨지기 쉬운 기반 클래스 회피 | 기반이 변하면 서브클래스가 깨짐 |
inheritance는 진정하고 안정적인 is-a 관계에만 사용하고, composition은 "이 동작이 필요하다"에 사용하세요.
Inheritance는 부모의 전체 인터페이스를 노출하므로, 서브클래스가 자신의 계약을 완전히 통제할 수 없습니다 — Stack extends ArrayList 누수가 전형적인 예입니다.
Composition은 관계를 명시적이고 교체 가능하게 유지하며, 이것이 의존성 주입, 전략 패턴, 그리고 대부분의 유연한 설계가 이에 의존하는 이유입니다.