# [[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

### Related Concepts

#### [아키텍처 및 기반 원칙]
- [[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*