게임 프로그래머를 위한 클래스 설계 (SOLID 원칙)
Source
Evernote/Technote scraps/조정훈, 게임 프로그래머를 위한 클래스 설계, NDC2012.md
Summary
본 문서는 NDC2012 에서 조정훈 발표자가 게임 프로그래밍 맥락에서 SOLID 원칙을 적용하는 방법을 설명한 자료입니다. KISS, DRY, HCLC 와 같은 기본 설계 철학을 바탕으로, 단일 책임 원칙 (SRP), 개방 폐쇄 원칙 (OCP), 리스코프 치환 원칙 (LSP), 인터페이스 격리 원칙 (ISP), 의존성 역전 원칙 (DIP) 을 게임 개발의 구체적인 예시 (인벤토리 시스템, 몬스터 AI, 렌더러 분리 등) 와 함께 설명합니다. 특히 ‘신 객체 (God Object)’ 방지, 상속 관계의 오용 (가방 vs 인벤토리), 그리고 추상화를 통한 모듈 간 결합도 낮추기의 중요성을 강조합니다.
Key Points
- 기본 설계 철학: KISS(간결함), DRY(복제 금지), HCLC(높은 응집도, 낮은 결합도) 를 준수해야 코드 유지보수성이 향상된다.
- SRP(단일 책임 원칙): 객체는 하나의 책임만 가져야 하며, 전지전능한 ‘God Object’ 나 ‘Monster Object’ 는 수정이 어려워지므로 피해야 한다.
- OCP(개방 폐쇄 원칙): 기존 코드의 수정 없이 확장이 가능해야 하며, 인터페이스는 고정되고 구현체는 확장되어야 한다 (예: USB 표준, 에러 리포터 인터페이스).
- LSP(리스코프 치환 원칙): 서브클래스는 베이스 클래스로 대체 가능해야 한다. 논리적 상속 관계가 아닌 경우 (예: 가방과 인벤토리의 무한 중첩 문제) 는 상속을 피해야 한다.
- ISP(인터페이스 격리 원칙): 객체는 사용하지 않는 인터페이스에 의존하지 않아야 한다. 필요에 따라 인터페이스를 세분화해야 한다 (예: 보스 몬스터와 일반 몬스터의 행동 인터페이스 분리).
- DIP(의존성 역전 원칙): 상위 모듈은 하위 모듈에 직접 의존하지 않고 추상화 (인터페이스) 에 의존해야 한다. 이를 통해 게임 로직과 렌더러 등의 결합도를 낮출 수 있다.