[TIL]디자인 패턴(2)
상태 패턴
유한 상태 머신을 구현할 때 쓰는 패턴. 가장 단순한 구현은 enum + switch 방식
핵심 개념
- 객체는 내부 상태가 바뀌면 동작도 바뀌어야함
- 상태별 동작은 독립적으로 정의됨 -> 새 상태를 추가해도 기존 상태에 영향 없음
- Enter, Execute, Exit 단계로 캡슐화
실전 활용 사례
- 적 AI: 순찰, 추적, 공격을 각각의 상태로 구조화
- Unity Animator와의 결합
- 계층적 상태머신으로 구현(하나의 상태가 복잡하게 된다면 그 안에서도 상태머신을 만들어서 사용)
옵저버 패턴
게임에서 어떤 객체가 직접 참조 없이 다른 객체에 알리는 메커니즘
주체(subject)는 관찰자(observer)를 모른다
핵심 개념
옵저버 패턴은 C#에 이벤트로 내장되어 있어 직접 만들 필요가 거의 없다
- 퍼블리셔(주체): 델리게이트 기반 이벤트를 생성
- 구독자(관찰자): 이벤트 핸들러를 만들어 이벤트를 구독
- 주체가 이벤트 발생 시키면 -> 구독자들의 핸들러가 호출 -> 각자 내부 로직 실행
이벤트 구독을 해제하지 않으면 가비지 컬렉션이 회수하지 못해 메모리 누수가 생김
실전 활용 사례
- 목표 달성, 승패 조건
- 플레이어/적 사망, 데미지, 아이템 획득
- UI 갱신
- 통계 업적 시스템
MVP 패턴
데이터와 UI를 한 클래스에 몰아넣으면 기능이 늘수록 확장성이 떨어진다
핵심 개념
- Unity에서는 기존 UI 프레임워크(Unity UI, UI Toolkit)가 자연스럽게 뷰 역할을 한다
- 프리젠터(Presenter): 모델에서 데이터를 가져와 뷰에 표시하도록 형식 지정
실전 활용 사례
- 체력/마나/경험치 바, 인벤토리, HUD 등 데이터 + UI 연동 전반
MVP는 대규모 프로젝트에서 업무 분배에 효율적이다
전략 패턴
같은 작업을 서로 다른 방식으로 수행해야하는 상황에 사용하는 패턴
조건문(if/switch)으로 알고리즘을 고르면 코드가 복잡해지고 유지보수가 어려워진다
핵심 개념
- Context: 전략을 사용하는 주체
- Strategy: 알고리즘 공통 인터페이스/추상클래스
- ConcreteStrategy: 실제 알고리즘 구현
전략 패턴 vs 상태 패턴 (자주 혼동!)
| 전략(Strategy) | 상태(State) | |
|---|---|---|
| 초점 | 어떻게 할 것인가 (방법) | 무엇을 할 것인가 (상태) |
| 교체 | 외부(클라이언트)가 전략 선택 | 상태가 스스로 다음 상태 결정 |
| 예 | 경로탐색 A* ↔︎ Dijkstra | 대기 → 걷기 → 점프 |
교체의 목적이 가장 큰 차이점!
실전 활용 사례
- RPG 스킬 시스템
- 적 AI 행동
- 경로 탐색
- 무기 발사
플라이웨이트 패턴
유사한 객체를 대량 생산하면 메모리 사용량이 급증하기 때문에 플라이웨이트를 사용하여 공통 데이터를 한 곳에 두고 여러 인스턴스가 참조하게 하여 메모리를 절약한다
핵심 개념
| 상태 | 설명 | 예 |
|---|---|---|
| 내재 상태(Intrinsic) | 모든 인스턴스가 공유하는 불변 데이터 | 유닛 이름, 메시, 텍스처, 기본 스탯 |
| 외재 상태(Extrinsic) | 인스턴스마다 다른 가변 데이터 | 위치, 회전, 크기, 현재 체력 |
주로 Scriptable Object를 통해 사용한다
실전 활용 사례
- 대규모 유닛 전투
- 숲, 도시 등 대량 환경 오브젝트
- 파티클, 타일 기반 맵
더티 플래그 패턴
변경이 생겼지만 비용이 큰 작업을 매 프레임 실행하는 것이 아닌 실제로 변경이 있을 때만 작업을 하는 것
"변경됨"을 표시하는 bool형 하나로 불필요한 재계산을 건너뛴다
핵심 개념
- 더티 플래그(IsDirty): 상태가 변경되었음을 나타내는 불리언
- MarkDirty(): 변경 발생 시 플래그를 true로
- Clean(): 작업 완료 후 플래그를 false로 초기화
실전 활용 사례
- 오픈 월드 스트리밍: 주변 섹터만 로딩/언로딩
- 트랜스폼 계층: 부모가 바뀌면 자식에 더티 전파, 월드 좌표는 필요할 때만 계산
- UI 레이아웃
