객체지향 프로그래밍(OOP)의 함정: 상속의 저주
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
개발 툴
대상자
- 대상: C++ 등 강형 언어를 사용하는 소프트웨어 개발자, 대규모 프로젝트 설계자
- 난이도: 중간 (OO 패턴 이해 필요)
핵심 요약
- OOP 상속의 주요 문제점:
- 다형성으로 인한 기능 제한 (예: animal
타입으로 인해 quack()
호출 불가)
- 모든 메서드를 기반 클래스에 강제 구현 (예: makeNoise()
, attack()
등)
- 런타임 캐스팅의 복잡성 (예: dynamic_cast
)
- 대안 아키텍처:
- Entity-Component-System (ECS) (데이터 중심, 플러그 앤 플레이)
- Procedural + Dead Objects (행동 없이 상태만 유지)
- 핵심 메시지:
- OOP는 이론적으로 우아하지만, 실무에서는 설계 문제를 유발
섹션별 세부 요약
1. OOP의 매력과 함정
- OOP의 장점:
- Chicken
과 Alligator
를 animal
기반으로 통합 가능
- 초기 설계 시 다형성으로 간결함 제공
- 문제점:
- 기능 확장 시 기반 클래스에 강제로 메서드 추가 필요 (예: makeNoise()
추가)
- 런타임에 특정 클래스 확인 필요 (예: getTag() == "Chicken"
)
2. 다형성의 한계
- 기반 클래스
animal
의 제약:
- zoo
벡터에 animal
타입만 저장 가능
- quack()
또는 roll()
호출 시 런타임 오류 발생
- 해결 시도:
- 모든 메서드를 기반 클래스에 구현 (예: makeNoise()
, attack()
)
- 예측 불가능한 행동 추가 (예: fly-kick?
)
3. OOP의 설계 패턴 의존성
- OOP는 자체 해결책을 요구:
- 런타임 캐스팅 (dynamic_cast
) 사용 필수
- 10개 이상의 서브클래스 관리 시 복잡성 증가
- 설계 패턴의 부담:
- OOP 자체가 문제를 일으키므로, 추가 설계 패턴 적용 필요
4. 대안 아키텍처: ECS
- ECS의 장점:
- 데이터 중심 설계 (예: Chicken
의 상태와 행동 분리)
- 플러그 앤 플레이 기능 (예: sparse set ECS
사용)
- 실무 적용 예시:
- GUI 프로젝트에서 ECS 사용 (예: LEGO 블록처럼 모듈화)
결론
- 대규모 프로젝트의 OOP 사용은 주의 필요:
- ECS나 절차적 프로그래밍으로 전환 권장
- OOP 상속은 마지막 수단으로 사용 (예: animal
기반 클래스에 dynamic_cast
사용)
- OOP는 이론적 우아함을 제공하지만, 실무에서는 설계 복잡성을 유발