[TIL]디자인 패턴(2)
댓글 0
댓글을 작성하려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 번째 댓글을 작성해보세요.
유한 상태 머신을 구현할 때 쓰는 패턴. 가장 단순한 구현은 enum + switch 방식
게임에서 어떤 객체가 직접 참조 없이 다른 객체에 알리는 메커니즘
주체(subject)는 관찰자(observer)를 모른다
옵저버 패턴은 C#에 이벤트로 내장되어 있어 직접 만들 필요가 거의 없다
이벤트 구독을 해제하지 않으면 가비지 컬렉션이 회수하지 못해 메모리 누수가 생김
데이터와 UI를 한 클래스에 몰아넣으면 기능이 늘수록 확장성이 떨어진다
MVP는 대규모 프로젝트에서 업무 분배에 효율적이다
같은 작업을 서로 다른 방식으로 수행해야하는 상황에 사용하는 패턴
조건문(if/switch)으로 알고리즘을 고르면 코드가 복잡해지고 유지보수가 어려워진다
| 전략(Strategy) | 상태(State) | |
|---|---|---|
| 초점 | 어떻게 할 것인가 (방법) | 무엇을 할 것인가 (상태) |
| 교체 | 외부(클라이언트)가 전략 선택 | 상태가 스스로 다음 상태 결정 |
| 예 | 경로탐색 A* ↔︎ Dijkstra | 대기 → 걷기 → 점프 |
교체의 목적이 가장 큰 차이점!
유사한 객체를 대량 생산하면 메모리 사용량이 급증하기 때문에 플라이웨이트를 사용하여 공통 데이터를 한 곳에 두고 여러 인스턴스가 참조하게 하여 메모리를 절약한다
| 상태 | 설명 | 예 |
|---|---|---|
| 내재 상태(Intrinsic) | 모든 인스턴스가 공유하는 불변 데이터 | 유닛 이름, 메시, 텍스처, 기본 스탯 |
| 외재 상태(Extrinsic) | 인스턴스마다 다른 가변 데이터 | 위치, 회전, 크기, 현재 체력 |
주로 Scriptable Object를 통해 사용한다
변경이 생겼지만 비용이 큰 작업을 매 프레임 실행하는 것이 아닌 실제로 변경이 있을 때만 작업을 하는 것
"변경됨"을 표시하는 bool형 하나로 불필요한 재계산을 건너뛴다
[TIL] 디자인 패턴 개요, 팩토리 패턴, 오브젝트 풀 패턴, 싱글톤 패턴, 커맨드 패턴
Develog는 단순히 글을 쓰는 공간이 아닙니다. 성장의 과정을 기록하고, 그 기록으로 나를 증명하며 원하는 기회를 얻는 곳이길 바랐습니다. 누군가의 꿈으로 향하는 중간다리가 되는 것, 그것이 Develog를 만든 이유입니다.

우리들의 게임 발매 이야기
Develog는 단순히 글을 쓰는 공간이 아닙니다. 성장의 과정을 기록하고, 그 기록으로 나를 증명하며 원하는 기회를 얻는 곳이길 바랐습니다. 누군가의 꿈으로 향하는 중간다리가 되는 것, 그것이 Develog를 만든 이유입니다.

