Search
🎨

[디자인 패턴 - 구조 패턴] 플라이웨이트 패턴 (Flyweight)

1. 의도

공유(sharing)를 통해 많은 수의 소립(fine-grained) 객체들을 효과적으로 지원합니다.
플라이웨이트 객체 - 공유가능한 객체

2. 활용성

GoF
응용프로그램이 대량의 객체를 사용해야 할 때
객체의 수가 너무 많아져서 저장 비용이 너무 높아질 때
대부분의 객체 상태를 부가적인 것으로 만들 수 있을 때
북적인 속성들을 제거한 후 객체들을 조사해보니 객체의 많은 묶음이 비교적 적은 수의 공유된 객체로 대체됄 수 있을 때
현재 서로 다른 객체로 간주한 이유는 이들 부가적인 속성때문이었지, 본질이 달랐던 것은 아닐 때
응용프로그램이 객체의 정체성에 의존하지 않을 때
플라이웨이트 객체들은 공유될 수 있음을 의미
식별자가 있다는 것은 서로 다른 객체를 구별해야한다는 의미이므로 플라이웨이트 객체 사용 불가
Head First
용도
어떤 클래스 인스턴스 하나로 여러개의 가상 인스턴스를 제공하고 싶을 때 사용
어떤 클래스의 인스턴스가 아주 많이 필요하지만 모두 똑같은 방식으로 제어해야 할때
장점
실행 시에 객체 인스턴스 개수를 줄여서 메모리를 절약할 수 있음
여러 가상 객체의 상태를 한 곳에 모아 둘 수 있음
단점
특정 인스턴스만 다른 인스턴스와 다르게 행동하게 할수 없음

3. 구조

UML Class Diagram

4. 참여자

참여자
역할
예시
Flyweight
Flyweight가 받아드릴 수 있고, 부가적인 상태에서 동작해야하는 인터페이스 선언
ConcreteFlyweight
Flyweight 인터페이스를 구현하고, 내부적으로 갖고 있어야 하는 본질적인 상태에 대한 저장소 정의 ConcreteFlyweight 객체 - 공유 할수 있는 것이어야 함 - 관리하는 어떤 상태라도 본질적인 것이어야 함
UnsharedConcreteFlyweight
모든 플라이웨이트 서브클래스들이 공유될 필요는 없음. Flyweight 인터페이스는 공유를 가능하게 하지만, 그것을 강요해서는 안됨. UnsharedConcreteFlyweight 객체가 ConcreteFlyweight 객체를 자신의 자식으로 갖는건 흔한 일임
FlyweightFactory
Flyweight 객체를 생성하고 관리하며, Flyweight 객체가 제대로 공유되도록 보장 사용자가 Flyweight 객체를 요청하면 FlyweightFactory 객체는 이미 존재하는 인스턴스를 제공하거나 생성함
Client
Flyweight 객체에 대한 참조자를 관리하며, Flyweight 객체의 부가적인 상태를 저장

5. 협력 방법

플라이웨이트 객체가 기능을 수행하는데 필요한 상태가 본질적인 것인지 부가적인 것인지 구분해야함
본질적인 상태 - ConcreteFlyweight에 저장
부가적인 상태 - 사용자가 저장하거나, 연산되어야 하는 다른 상태로 관리
사용자는 연산을 호출할 때 자신에게만 필요한 부가적 상태를 플라이웨이트 객체에 매개 변수로 전달
사용자는 ConcreteFlyweight의 인스턴스를 직접 만들 수 없음
ConcreteFlyweight 객체를 FlyweightFactory 객체에서 얻어야함
이를 통해 플라이웨애트 객체 공유 가능

6. 결과

7. 예시 코드