[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 레이아웃