Structural Pattern
각 개체에 모든 데이터를 보관하는 대신 여러 개체 간의 상태의 공통 부분을 공유하여 RAM에 더 많은 개체를 보관할 수 있는 패턴
문제
총 쏘는 게임을 만들어서 친구에게 보내줬는데 친구는 RAM이 부족해서 충돌발생!
총알, 미사일 또는 파편 같은 입자는 많은 데이터를 포함하는 개체로 표시해 화면 상 절정에 이르렀을 경우 새로 생성된 입자들을 RAM이 감당하지 못해서 충돌이 발생
해결
color와 sprite 필드가 많은 메모리를 사용하는데 심지어 모든 입자에 걸쳐 거의 같은 데이터를 저장합니다.
vector, speed, coords와 같은 상태는 입자마다 고유하고 시간에 따라 변화합니다. 반면 color와 sprite는 입자마다 일정하게 유지됩니다.
이러한 상수 데이터들을 고유한(Intrinsic) 상태라고 합니다. 다른 개체들을 이 데이터를 읽을 수만 있고 변경할 수는 없습니다. 외부에서 변경 가능한 경우 공유한 상태라고 합니다.
Flyweight 패턴은 객체 내부에서 상태 저장을 하는 대신 상태에 의존하는 특정 메서드들에 전달하도록 합니다. 고유한 상태만 객체에 유지되므로 Context가 다른 곳에서 재사용할 수 있습니다. 이러한 객체들은 변형이 적기 때문에 훨씬 적은 수의 객체만 있으면 됩니다.
이제 Particle 클래스에서 공유한 상태를 추출해 고유한 상태만 저장하는 객체를 플라이웨이트라고 합니다.
공유한 상태 스토리지
같은 Flyweight 객체가 다른 Context에서 사용될 수 있으므로 수정되는지 확인해야 합니다. 생성자를 통해 상태를 한 번만 초기화하고 필드를 다른 객체에 노출해서는 안 됩니다.
플라이웨이트 팩토리
다양한 Flyweight를 관리하기 위해 Factory 메서드를 생성할 수 있습니다. Client에서 고유한 상태를 받아 일치하는 기존 객체를 찾아 반환합니다. 그렇지 않으면 새로운 Flyweight를 생성하여 추가합니다.
적용
- 많은 수의 개체들을 지원해야 하는데 RAM을 거의 사용한 경우
- 수많은 유사 개체를 생성해야 할 때
- 대상 장치에서 사용할 수 있는 모든 RAM을 소모할 때
- 개체들이 여러 중복 상태들이 포함되어 있고, 상태들이 추출된 후 개체 간에 공유될 수 있을 때
구조
❗️플라이웨이트는 최적화에 불과합니다.
패턴을 적용하기 전에 메모리에 유사한 객체들을 대량으로 보유하는 것과 관련된 RAM 소비 문제가 있는지 확인하고 다른 방법으로 해결될 수 없는지 확인하세요.
Flyweight
- 여러 개체들 간에 공유할 수 있는 상태 부분이 포함
- 같은 플라이웨이트 개체가 다양한 Context에서 사용될 수 있습니다
- 플라이웨이트 내부에 저장된 상태 - 고유한(Intrinsic) 상태
- 플라이웨이트의 메서드에 전달된 상태 - 고유한(extrinsic) 상태
Context
- 공유한 상태를 포함
- 플라이웨이트 개체 중 하나와 쌍을 이루면 개체의 전체 상태를 나타냄
Client
- 플라이웨이트의 공유된 상태를 저장하거나 계산
- 일부 Context 데이터를 메서드들의 매개변수로 전달하여 런타임에 설정할 수 있는 템플릿 개체
Flyweight Factory
- 기존 Flyweight들을 관리
- client는 Flyweight를 직접 만들지 않고 고유한 상태 일부를 전달해서 Factory를 호출
- 이전에 생성된 Flywight가 있으면 반환하고 아니면 새로 생성
장단점
✅ 장점
- 유사한 개체들이 많은 경우에 RAM을 절약할 수 있습니다.
❎ 단점
- 플라이웨이트 메서드를 호출할 때마다 Context 데이터의 일부를 다시 계산해야 한다면 CPU 주기 대신 RAM을 절약하고 있을 수도,,
- 코드가 복잡해져서 팀원은 개체(Entity) 상태가 왜 그렇게 분리되었는지 알기 어렵습니다.
