[디자인 패턴] 오브젝트 풀, 전략 패턴, 커맨드 패턴

 

Unity에서 자주 쓰는 디자인 패턴 3가지  # 2탄

 

1. 오브젝트 풀 패턴

프레임 속도를 유지하려면 자주 생성되는 요소를 일부 메모리에 등록하는 것이 좋다.

 

ex. 최근 죽인 적을 메모리에서 없애는 대신 다시 사용할 수 있도록 오브젝트 풀에 추가

  - 엔티티의 새로운 인스턴스를 로드하는 초기의 초기화 비용이 들지 않음

  - 유니티에는 오브젝트 풀링이 API에 구현되어 있음.

 

오브젝트 풀의 구성

ObjectPool : 객체의 풀을 관리함. 객체 생성/관리/파기 의 책임

ReusablePool : 실제로 재사용될 객체. 

Client : 필요할 때 객체를 요청하고 사용한 뒤에 반환.

 

장점)

메모리 사용량을 예측하기 용이, 성능의 향상

 

단점)

이미 C#이 메모리 최적화가 뛰어나서 굳이 필요없는 경우도 있다.

객체의 상태를 예측하기 어렵다.

 ex. 몬스터 HP 값이 있는데, 풀에서 HP를 따로 저장하는 경우

      나중에 다시 꺼낼 때 몬스터만 나오고 HP는 없는 상태로 등장할 수 있음.

 

 

2. 전략 패턴

- 다양한 동작을 구현하는 상황

- 런타임에 특정 동작을 객체에 바로 할당할 수 있음

 

전략 패턴의 구성

Context : 자신의 작업을 수행하는데 필요한 전략을 선택하는 클래스

Strategy : 전략 인터페이스를 구현한 클래스들로, 특정 행동을 제공

Client : 클라이언트에서 context 클래스를 생성

 

장점)

캡슐화 잘 됨, 런타임에 객체가 사용하는 알고리즘 교환 가능

 

단점)

상태패턴과의 혼동. 구조가 유사하지만 의도가 매우 다름

전략패턴) 같은 문제를 해결하는 여러 알고리즘이 있을 때, 이들 중 하나를 런타임에 선택해야 할 때

                (ex. 상황에 따라 적합한 정렬 알고리즘 고르기) 즉, 알고리즘의 선택에 중점

상태패턴) 객체가 여러 상태를 가지고 있고, 상태에 따라 행동이 달라져야 할 때 (즉, 상태에 따른 행동 변경)

 

 

3. 커맨드 패턴

 

 

커맨드 패턴의 구성

Client : 커맨드 객체 생성, 어떤 receiver와 연결될 지 결정

Invoker : 커맨드를 받아서 실행

command : 실행될 모든 명령에 대한 인터페이스

Receiver : 실제로 작업을 수행할 객체

 

장점)

실행하는 객체와 호출하는 객체의 분리

명령을 큐에 넣어서 리플레이, 매크로, 명령 큐 등을 구현할 수 있다.

명령한 기록을 모두 남길 수 있다.

기록을 재생해 리플레이 시스템을 만들 수 있다.

 

단점)

코드의 복잡성 ) 각 명령을 하나의 클래스로 구현해야 함