1. 용도
공유를 통해 많은 수의 소립 객체들을 효과적으로 지원합니다.
2. 활용성
- 응용 프로그램이 대량의 객체를 사용해야 할 때
- 객체의 수가 너무 많아져 저장 비용이 너무 높아질 때
- 대부분의 객체 상태를 부가적인 것으로 만들 수 있을 때
- 부가적인 속성들을 제거한 후 객체들을 조사해 보니 객체의 많은 묶음이 비교적 적은 수의 공유된 객체로 대체될 수 있을 때
- 응용프로그램이 객체의 정체성에 의존하지 않을 때
3. Class Diagram과 구조
[Flyweight] - Flyweight가 받아들일 수 있고, 부가적 상태에서 동작해야하는 인터페이스를 선언합니다.
[ConcreteFlyweight] - Flyweight 인터페이스를 구현하고 내부적으로 갖고 있어야 하는 본질적 상태에 대한 저장소를 정의합니다.
[UnsharedConcreteFlyweight] - 모든 플라이급 서브클래스들이 공유될 필요가 없기에 공유되지 않는 클래스를 정의합니다.
[FlyweightFactory] -플라이급 객체를 생성하고 관리하며, 플라이급 객체가 제대로 공유되도록 보장합니다.
[Client] -플라이급 객체에 대한 참조자를 관리하며 플라이급 객체의 부가적 상태를 저장합니다.
플라이급 객체가 기능을 수행하는 데 필요한 상태가 본질적인 것인지 부가적인 것인지를 구분해야 합니다. 본질적 상태는 ConcreteFlyweight에 저장해야 하고, 부가적인 상태는 사용자가 저장하거나, 연산되어야 하는 다른 상태로 관리해야 합니다. 사용자는 연산을 호출할 때 자신에게만 필요한 부가적 상태를 플라이급 객체에 매개변수로 전달합니다. 사용자는 ConcreteFlyweight의 인스턴스를 직접 만들 수 없습니다. 사용자는 ConcreteFlyweight 객체를 FlyweightFactory 객체에서 만들어야 합니다.
4. 장단점
장점
- 객체 공유를 통한 저장소 절약 - 객체의 인스턴스의 전체 수와 본질적 상태의 양을 줄일 수 있습니다. 이는 공유할 상태가 많아질 수록 절약됩니다.
단점
- 부가적 상태의 연산과 전송에 드는 런타임 비용 생성 - 저장 공간이 줄어드는 대신 부가적 상태를 만들기 위한 연산 시간이 필요합니다.
5. 구현 방법
- 부가적 상태 제외 - 공유할 객체에서 부가적인 상태를 식별하고 분리하는 가에 패턴 활용 여부가 달려있습니다.
- 공유할 객체 관리 - FlyweightFactory를 통해 사용자가 특정한 플라이급 객체를 찾아내도록 하여 이를 활용하도록 합니다.
'C++공부 > GoF의 디자인 패턴' 카테고리의 다른 글
| 프록시(Proxy) (0) | 2022.07.06 |
|---|---|
| 퍼사드(Facade) (0) | 2022.07.06 |
| 장식자(Decorator) (0) | 2022.07.06 |
| 복합체(Composition) (0) | 2022.07.06 |
| 가교(Bridge) (0) | 2022.07.06 |