Polymorphism

새 타입이 추가될 때마다 if 나 switch 에 타입 분기를 늘리는 구조는 변화를 계속 호출자 쪽으로 끌어옵니다. 결제 수단이 하나 늘 때마다 서비스 코드 여러 곳을 같이 고쳐야 한다면 시스템은 확장되는 것이 아니라 조건문에 묶여 굳어 가는 것입니다.

객체지향이 다형성을 중시한 이유도 행동의 차이를 호출자 바깥으로 밀어내기 위해서였습니다. 새로운 구현체를 추가해도 기존 호출자는 같은 계약만 따르면 되고, 구체 동작의 차이는 각 타입이 책임지게 하자는 방향입니다. 가상 메서드와 인터페이스 기반 설계가 중요한 것도 이 확장 방식과 맞닿아 있습니다.

호출자는 공통 계약에 정의된 메서드를 호출합니다. 런타임은 실제로 전달된 객체의 구체 타입을 보고 그 타입이 구현한 메서드를 선택해 실행합니다. 그래서 같은 호출이라도 이메일 알림 객체와 SMS 알림 객체는 서로 다른 내부 로직으로 응답할 수 있습니다. 호출자 입장에서는 역할은 같고 실행 방식만 달라지는 구조입니다.

다형성은 상속과 자주 같이 설명되지만 둘은 같은 개념이 아닙니다. 상속 없이도 인터페이스 구현과 합성만으로 다형성을 만들 수 있고, 상속 계층이 있다고 해서 자동으로 좋은 다형성이 생기는 것도 아닙니다. 핵심은 호출자가 구체 타입 지식에서 얼마나 자유로워졌는가입니다.

결제 전략, 알림 채널, 파일 저장기, 렌더러처럼 역할은 같고 구현체만 달라지는 자리에 다형성이 특히 잘 맞습니다. 반대로 타입 종류가 거의 고정돼 있고 차이도 단순하다면, 다형성을 위해 추상화 계층을 하나 더 두는 비용이 이득보다 클 수 있습니다.