숏컷 코드
text
새 타입 추가
-> 기존 giant switch 수정 반복
-> OCP 약함
새 타입 추가
-> 새 전략 / 새 factory 등록
-> OCP 강함문법과 예시
OCP의 핵심은 "새 규칙 추가가 기존 중심 로직 수정으로 이어지지 않는가"다
게임 코드에서 OCP는 클래스를 절대 수정하지 말라는 뜻이 아닙니다. 핵심은 새 무기, 새 스킬, 새 적 행동을 넣을 때 중심 흐름을 계속 뜯어야 하는지 보는 것입니다.
switch (weaponType)가 무기 종류마다 계속 길어지면 확장은 되지만 폐쇄는 안 된 구조입니다.
text
나쁜 예
- ItemUseSystem switch에 Potion, Bomb, Scroll, Buff를 계속 추가
더 나은 예
- IItemUseStrategy 등록
- 새 아이템은 새 구현 추가OCP는 패턴과 등록 지점이 같이 있어야 실제로 작동한다
Strategy, Factory, Command, State 같은 패턴은 OCP를 구현하는 수단입니다. 하지만 새 구현을 연결하는 등록 지점이 없으면 결국 다른 switch로 돌아갑니다. 그래서 OCP는 "행동 분리"와 "연결 방식 분리"를 같이 봐야 합니다.
Unity에서는 Inspector 확장도 OCP를 도울 수 있다
ScriptableObject 자산, prefab reference, interface 기반 목록을 통해 새 구현을 Inspector에서 연결할 수 있으면, 코드 수정 없이 규칙을 확장하기 쉬워집니다. 반대로 enum 추가 후 모든 분기문을 수정하는 구조는 Unity 편집 경험과도 잘 맞지 않습니다.
핵심 질문은 "새 타입 추가"인지 "기존 규칙 수정"인지다
새 무기 하나를 넣을 때 기존 코드 수정을 피할 수 있다면 OCP 쪽으로 잘 가고 있는 것입니다. 반대로 밸런스 숫자 조정이나 작은 연출 차이처럼 "새 타입"이 아니라 "기존 규칙 수정"에 가까운 문제라면 패턴 추가보다 데이터화가 더 낫습니다.
OCP를 볼 때 핵심
| 상황 | 적합한 선택 |
|---|---|
| 새 타입 추가 때 중심 switch를 계속 수정할 때 | OCP 약함, 패턴 분리 검토 |
| 새 행동을 새 클래스/자산 추가로 해결할 수 있을 때 | OCP 강함 |
| 연결 지점만 바꾸면 새 기능이 들어올 때 | 등록 구조 유지 |
| 타입 수가 적고 거의 안 늘어날 때 | 단순 분기도 허용 가능 |
| Inspector 자산 추가만으로 확장이 가능할 때 | Unity와 잘 맞는 OCP 구조 |
특이 케이스와 주의할 점
흔한 실패는 switch를 없애겠다고 모든 작은 차이까지 클래스 분리하는 것입니다. 타입 수가 거의 안 늘고 규칙도 안정적이면 단순 분기가 더 읽기 쉬울 수 있습니다. OCP는 변경 압력이 큰 축에 우선 적용하세요.
text
실패 예시
- 데미지 배율 숫자만 다른 20종 타입을 전부 별도 클래스화
결과
- switch는 줄었지만 구현 파일만 과하게 늘어남
- 실제 알고리즘 변화는 거의 없음참고 링크
1 sources