알림 채널마다 로깅·재시도 기능을 조합하다 보니 하위 클래스가 계속 늘어납니다. 어떤 책임을 분리하고 상속과 조합 중 무엇을 선택하나요?

상속과 조합은 모두 재사용과 다형성을 만들 수 있지만, 기본 선택은 조합하고 필요한 동작을 위임하는 쪽에 두겠습니다. 상속은 자식이 부모의 타입으로 대체될 수 있고 부모가 정한 상태·수명·호출 순서를 함께 지켜야 할 때 적합합니다. 단순히 코드 몇 줄을 재사용하려고 상속하면 부모의 변경이 자식에게 전파되고, 사용하지 않는 기능까지 물려받는 결합이 생깁니다.

예를 들어 EmailNotifier, SmsNotifier가 공통 로그 코드를 재사용하려고 BaseNotifier를 상속한다고 해 보겠습니다. 나중에 부모가 전송 전 재시도나 특정 초기화를 강제하면 모든 자식이 그 정책에 묶입니다. Notifier가 Channel과 RetryPolicy를 받아 send()를 조합하고, 실제 전송은 각 협력 객체에 위임하면 알림 채널과 재시도 정책을 독립적으로 바꿀 수 있습니다. 객체가 무엇인지보다 어떤 역할을 협력하는지가 중심이 되는 구조입니다.

그렇다고 상속을 금지할 필요는 없습니다. 공통 추상 타입의 계약이 명확하고, 모든 하위 타입이 그 계약을 자연스럽게 만족하며, 계층의 안정성이 재사용 이점보다 크다면 상속이 읽기 쉬울 수 있습니다. 조합은 객체와 연결부가 늘고 위임 코드가 생기는 비용이 있으므로 작은 고정 계층에서는 오히려 과할 수 있습니다. 부모 구현을 재사용하고 싶다는 이유만으로 상속하지 말고, 대체 가능성과 변경 전파 범위를 기준으로 결정하겠습니다.

각 변화 축을 협력 객체로 나눕니다

채널은 외부 전송 방식, 재시도 정책은 어떤 오류를 다시 보낼지, 로거는 안전한 맥락을 남길지를 맡깁니다. Notifier가 이들을 받아 위임하면 Email·SMS·푸시와 재시도 정책을 독립적으로 조합할 수 있습니다. 재시도는 전송 전 확실한 실패와 timeout처럼 이미 수신됐을 수도 있는 불확정 오류를 구분하고, 외부 채널이 멱등 키를 지원하는지 확인해야 합니다. 정책 객체가 채널의 SDK 예외를 그대로 노출하면 분리한 책임이 다시 결합됩니다.

상속은 행동 계약으로 제한합니다

부모가 한 번 전송하고 실패를 알린다는 계약을 자식이 두 번 호출하거나 예외를 삼키면 코드가 재사용돼도 치환되지 않습니다. 모든 자식이 부모의 입력·결과·수명·호출 순서를 자연스럽게 지킬 때만 상속을 선택하고, 공통 구현 몇 줄은 위임으로 옮기겠습니다. 조합은 객체와 생성 순서가 늘어나는 비용이 있으므로 컴포지션 루트에 조립 책임을 둡니다. 새 채널 추가와 정책 교체가 기존 클래스 계층을 얼마나 건드리는지 계약 테스트로 비교하겠습니다.

구체적인 경계 사례

부모 생성자에서 재정의 가능한 메서드를 호출하면 자식 필드 초기화가 끝나기 전에 자식 동작이 실행될 수 있습니다. 부모 내부 호출 순서에 의존하는 자식이 많을수록 부모의 작은 리팩터링도 영향이 넓어지는 취약한 기반 클래스 문제가 생깁니다. 공통 수명 절차가 필요하면 확장 가능한 지점을 제한한 템플릿 메서드를 쓰되, 호출 순서와 예외 시 정리를 계약으로 고정하겠습니다.

조합도 위임 객체가 다시 상위 객체를 호출하면 순환과 숨은 재진입이 생길 수 있습니다. 데이터 흐름과 소유자를 명시하고 장기 보관할 콜백의 수명을 관리합니다. 정책이 두세 개뿐이고 앞으로 변할 근거가 없다면 수십 개 클래스로 나누지 않고 함수 매개변수나 작은 객체부터 시작해 실제 변경이 발생하는 경계를 기준으로 확장하겠습니다.