지양해야 하는 것은 싱글톤, mutable state, for/if 자체가 아니라, 전역 상태에 대한 과도한 의존, 분산된 상태 변경, 조건문 남발, 그리고 실제 완료 조건 대신 임의의 타이머에 의존하는 설계다. + Lock.
- Lock 없으면 Race Condition 가능, Lock 잘못 잡으면 Deadlock 가능
- 싱글톤 / 글로벌 변수
- OCP를 “단번에 깨버린다”는 표현은 정확하지 않아.
- 다만 전역 접근에 강하게 의존하면 결합도가 높아지고 테스트/교체/확장이 어려워져서 OCP, DIP 같은 설계 원칙을 해치기 쉬워.
- 특히 GameManager.Instance.Xxx() 같은 호출이 코드 전역에 퍼지면 수정 영향 범위가 커져.
- Mutable 변수 + for/if
- 이것도 자체로 나쁜 게 아니야. 게임 코드는 상태 변화가 많아서 mutable state, for, if는 매우 흔해.
- 문제는 같은 상태를 여러 곳에서 제멋대로 바꾸거나, 조건문이 계속 늘어나서 새 기능 추가 때마다 기존 코드를 수정해야 하는 경우야.
- 예: if (type == Fire) ... else if (type == Ice) ...가 계속 늘어나면 OCP 위반 신호가 될 수 있음.
- 불필요한 타이머 임시 로직
- 이건 확실히 코드 스멜인 경우가 많아.
- 예: “0.5초 뒤면 아마 로딩 끝났겠지” 같은 식으로 타이머를 넣는 건 레이스 컨디션과 환경 의존 버그를 만들기 쉬워.
- 가능하면 이벤트, 콜백, Task 완료, 상태 변화 신호를 기다리는 방식이 더 안정적이야.