Inheritance

비슷한 타입이 늘어날 때마다 같은 필드와 메서드를 복사하면 수정 비용이 빠르게 커집니다. 공통 코드를 한곳으로 끌어올리고 싶어지고, 상속은 그 요구에 가장 직접적인 재사용 메커니즘처럼 보입니다. 그래서 초창기 객체지향 설계에서 상속은 거의 기본 선택지처럼 쓰였습니다.

초기 객체지향은 재사용과 분류 체계를 상속 중심으로 설명하는 경우가 많았습니다. 하지만 실무에서는 깊은 상속 트리가 부모 변경에 취약하고, 하위 타입을 부모 구현 세부에 과하게 묶는다는 문제가 반복해서 드러났습니다. 그래서 지금은 상속을 강력하지만 비용이 큰 도구로 보는 시각이 일반적입니다.

하위 클래스는 부모의 필드와 메서드를 물려받고, 필요하면 새 필드와 메서드를 추가하거나 기존 메서드를 재정의합니다. 이 구조가 유효하려면 하위 타입이 부모 타입이 기대하는 계약을 깨지 않아야 합니다. 즉 단순한 코드 재사용이 아니라 타입 관계로서도 자연스러워야 합니다.

상속은 보통 is-a 관계를 전제로 하고, 조합은 has-a 관계를 전제로 합니다. 상위 개념과 하위 개념의 의미가 분명하고 치환 가능성이 유지될 때는 상속이 맞지만, 공통 코드를 재사용하고 싶은 정도라면 조합이 더 안전한 경우가 많습니다.

프레임워크 베이스 클래스, 공통 실행 흐름을 가진 작업 타입, 분류 체계가 명확한 도메인 모델에서는 상속이 유효할 수 있습니다. 다만 재사용 편의만 보고 계층을 늘리면 부모 구현 변화 하나가 멀리 있는 자식 클래스까지 연쇄적으로 흔드는 구조가 되기 쉽습니다.