Polymorphism (다형성)

📌 Brief 실 Summary

다형성(Polymorphism)은 객체 지향 프로그래밍에서 객체가 자신의 타입에 따라 적절한 동작을 스스로 수행하게 하는 메커니즘이다 [1, 2]. 리팩토링 원칙에서 다형성은 주로 길고 복잡한 조건문(switch 또는 if-else)을 하위 클래스의 재정의된 메서드로 대체하여 코드의 중복을 제거하고 명확성을 높이는 데 사용된다 [1, 3, 4]. 이를 통해 새로운 타입이나 조건이 추가될 때 기존 코드를 수정할 필요 없이 새로운 클래스를 추가하기만 하면 되는 유연성을 제공하여 아키텍처의 변경을 관리하기 쉽게 만든다 [3, 5, 6].

📖 Core Content

조건부 로직의 단순화 및 유연성 확보: 절차지향적 코드에서 흔히 나타나는 긴 분기문(Switch 구문 등)은 중복을 유발하고, 새로운 조건이 추가될 때마다 관련된 모든 조건문을 찾아 수정해야 하므로 유지보수를 매우 어렵게 만든다 [3, 7]. 다형성을 활용하면 명시적인 조건문을 다형성 메시지로 변경하여 분기 로직을 인코딩할 수 있으며, 객체에게 타입을 묻고 행동을 결정하는 대신 단순히 행동을 호출(invoke)하여 객체 스스로 올바른 동작을 수행하도록 만들 수 있다 [2, 4, 5].
'조건식을 다형성으로 바꾸기(Replace Conditional with Polymorphism)' 프로세스: 객체의 타입에 따라 다른 동작을 선택하는 조건문이 있을 때, 각 조건의 분기를 하위 클래스의 재정의(overriding)된 메서드로 옮기고 원본 메서드는 추상(abstract) 메서드로 선언하는 리팩토링 기법이다 [1, 8]. 이 과정의 전제 조건으로 '타입 코드를 하위 클래스로 바꾸기(Replace Type Code with Subclasses)' 또는 '타입 코드를 상태/전략으로 바꾸기(Replace Type Code with State/Strategy)'를 적용하여 다형성 동작을 호스팅할 상속 구조를 우선적으로 구축해야 한다 [9, 10].
개방-폐쇄 원칙(Open/Closed Principle) 준수: 다형성을 통해 분기별 로직을 별도의 클래스로 격리하면, 새로운 조건이나 타입이 요구될 때 기존 로직을 '수술'하는 대신 새로운 구체 클래스(Concrete Class)를 추가하는 것만으로 확장이 가능하다 [3, 6]. 이러한 설계는 단일 조건 로직이 프로그램의 여러 곳에 흩어져 있을 때(중복 코드) 진가를 발휘하며, 변화하는 변형(variant)들을 클라이언트로부터 숨겨 시스템 의존성을 낮춘다 [5, 7, 11].
Null 객체 패턴(Introduce Null Object)을 통한 다형성 적용: Null 값을 확인하는 반복적인 조건문 역시 다형성을 통해 우아하게 해결할 수 있다 [2]. Null 값을 나타내는 특수 하위 클래스(Null Object)를 생성하고 해당 타입의 기본 동작을 재정의함으로써, 명시적인 null 체크 로직 없이도 다형성 호출을 통해 객체가 적절한 행동을 위임받아 수행하게 된다 [2, 12].

⚖️ Trade-offs & Caveats

과도한 엔지니어링(Overkill) 위험: 단일 메서드에만 영향을 미치는 소수의 조건만 존재하며 향후 조건이 변경되거나 확장될 것으로 예상되지 않는 경우, 상속과 다형성을 도입하는 것은 오히려 불필요한 복잡성을 초래할 수 있다 [13]. 이 경우에는 다형성 대신 '매개변수를 명시적 메서드로 바꾸기(Replace Parameter with Explicit Methods)' 같은 단순한 기법이 더 적합할 수 있다 [13].
객체 생명주기에 따른 상속 적용 제약: 하위 클래스를 활용해 다형성을 구현할 때 주의해야 할 가장 큰 제약은 '객체는 생성된 이후 자신의 클래스를 런타임에 변경할 수 없다'는 점이다 [14]. 객체의 타입 코드나 상태가 수명 주기 동안 변경되어야 하거나, 해당 클래스가 이미 다른 이유로 하위 클래스화되어 있다면 단순 상속을 사용할 수 없다 [9, 15]. 이러한 제약 상황에서는 상속 대신 '상태 패턴(State Pattern)'이나 '전략 패턴(Strategy Pattern)'을 결합하여 간접 참조(indirection) 계층을 추가하는 구조적 타협이 필요하다 [14-16].

🔗 Knowledge Connections

[아키텍처 및 기반 원칙]

Open/Closed Principle (개방-폐쇄 원칙)
- 연결 이유: 다형성을 통한 리팩토링의 핵심 목표 중 하나가 기존 코드를 변경하지 않고 새로운 동작을 확장할 수 있게 만드는 것이기 때문이다 [3, 6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다형성이 어떻게 코드의 결합도를 낮추고 시스템의 유지보수성을 극대화하는지 아키텍처 관점에서 이해할 수 있다.

[코드 구조 결함 (Code Smells)]

Switch Statements (Switch 문)
- 연결 이유: 다형성 리팩토링의 가장 주요한 타겟이자 대상이 되는 코드 냄새이다 [5, 7].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 지향 시스템에서 중복된 조건문이 왜 치명적인 유지보수 문제를 일으키는지 파악할 수 있다.
Primitive Obsession (기본 타입 집착)
- 연결 이유: 타입 코드(Type Code)를 단순 정수나 문자열 같은 기본 타입으로 사용할 때 다형성 적용을 방해하는 원인이 된다 [17].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기본 타입을 객체나 하위 클래스로 격상시키는 것이 다형성 설계의 첫 단추임을 이해할 수 있다.

[구현 및 리팩토링 패턴]

State/Strategy Pattern (상태/전략 패턴)
- 연결 이유: 객체의 타입이나 상태가 런타임에 변경되어야 하는 경우, 단순 상속을 활용한 다형성의 한계를 극복하기 위해 필수적으로 결합되어야 하는 디자인 패턴이다 [14, 15].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다형성을 통한 위임(Delegation)의 구체적인 구현 방식과 구조적 유연성을 배울 수 있다.
Introduce Null Object (Null 객체 도입)
- 연결 이유: 조건문의 일종인 반복적인 Null 체크를 다형성을 사용하여 우아하게 처리하는 특수 사례이다 [2].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다형성의 범위를 상태 및 타입 검증을 넘어 예외/비정상 상태(Null)의 기본 처리로까지 확장하는 방법을 이해할 수 있다.

Deeper Research Questions

상태 패턴(State)과 전략 패턴(Strategy)을 이용하여 다형성을 구현할 때, 두 패턴 간의 선택 기준과 각각이 시스템 구조에 미치는 유지보수 비용은 어떻게 다른가?
단순한 조건문 분기와 다형성을 이용한 객체 구조화 사이에서, 설계가 '오버엔지니어링'으로 빠지지 않도록 판단할 수 있는 실무적 임계점(Threshold)은 무엇인가?
동적 바인딩(Dynamic Binding)이 수반되는 다형성이 성능에 민감한 시스템에서 오버헤드를 발생시킬 수 있는가? 그렇다면 가독성과 성능 사이의 반대급부를 어떻게 조율할 것인가?
Null Object 패턴을 통해 다형성으로 Null 체크를 제거할 때, 반드시 포착해야 하는 시스템의 오류가 은닉되는 부작용(예외 덮어쓰기)을 방지하기 위한 설계 한계는 무엇인가?
다형성을 통해 계층이 분리된 도메인 모델이 데이터베이스의 단일 테이블과 매핑될 때 발생하는 직렬화 및 스키마 구조의 불일치 문제는 어떻게 해결해야 하는가? (소스에 관련 정보가 부족합니다. 후속 조사가 필요합니다.)

Practical Application Contexts

Implementation: 복잡하게 얽힌 Switch문이나 중첩된 If-Else문을 발견했을 때, 다형성을 지원할 수 있는 인터페이스나 상위 클래스를 생성한 뒤 각 조건 분기를 하위 클래스의 재정의된 메서드로 추출하여 구현한다.
System Design: 소프트웨어 설계 초기 단계에서 변화할 수 있는 타입(예: 영화의 분류, 직원의 급여 체계 등)을 수용해야 할 때, 타입 코드를 기반으로 한 다형성 구조를 미리 반영하여 설계 변경에 유연한 아키텍처를 구축한다.
Operation / Maintenance: 레거시 코드 유지보수 중 특정 로직을 변경하기 위해 프로그램 전반에 흩어진 분기문을 모두 찾아야 하는 '산탄총 수술(Shotgun Surgery)' 냄새가 발생할 때, 다형성을 도입하여 변경 지점을 하나로 모은다.
Learning Path: 리팩토링의 기본기인 '메서드 추출(Extract Method)'과 '메서드 이동(Move Method)'을 마스터한 뒤, 객체 지향 프로그래밍의 핵심인 다형성 관련 리팩토링 기법을 학습하여 디자인 패턴의 활용으로 나아간다.
My Project Relevance: 할인 정책, 등급 권한 처리 등 변동성이 높은 규칙이 포함된 비즈니스 로직을 리팩토링하여, 요구사항이 새롭게 추가될 때마다 기존 코드를 건드리지 않고 새로운 정책 클래스만 추가하는 안정적인 프로젝트 관리를 수행한다.

Adjacent Topics

Test-Driven Development (테스트 주도 개발)
- 확장 방향: 조건식을 다형성 구조로 대폭 변경하는 리팩토링을 수행할 때, 기존 동작이 변하지 않았음을 보장하기 위해 반드시 갖춰져야 하는 테스트의 자동화 및 안전망 구축 방법론으로 확장하여 학습한다.
Code Smells (코드 냄새)
- 확장 방향: 다형성이 필요한 상황을 식별할 수 있는 다양한 징후들(예: 반복되는 조건문, 기능 욕심, 데이터 뭉치 등)을 어떻게 민감하게 포착하고 평가할 것인지에 대한 통찰로 확장이 가능하다.

Last updated: 2026-05-03

9.9 KiB Raw Blame History