의도
작은 크기의 객체들의 수가 폭발적으로 늘어나는 것을 방지하기 위해 공유 개념을 도입.
동기
객체 지향적으로 설계함으로써 많은 유연성과 재활용성을 기대 할 수 있기는 하지만 늘어만 가는 클래스들을 보고 있노라면 그 비용이 만만치 않음을 느낀다.
클래스를 작은 단위 요소까지 나누어서 설계를 한다면 어플리케이션의 응용성을 높일 수 있고, 해당 요소들을 일관성 있게 다룰 수도 있으며, 요소들에 새로운 기능을 추가하거나 수정한다고 해도 다른 기능에 아무런 영향을 주지 않을 수 있다. 하지만 너무 작은 요소들까지 객체로 다룰때 폭발적으로 늘어나는 객체를 처리 하는 비용은 만만치가 않다. Flyweight 패턴은 이러한 문제를 '공유'를 통해 해결하고자 하는 것이다.
구조
* Flyweight
- extrinsic한 데이터를 받아 들이고, 동작해야 하는 인터페이스를 선언하고 있다.
* ConcreteFlyweight
- Flyweight 인터페이스를 구현 하고, intrinsic(변하지 않는, 본질적인) 상태에 대한 저장소를 정의한다.
* UnsharedConcreteFlyweight
- 모든 Flyweight서브 클래스들이 공유될 필요는 없기에 이런 클래스가 만들어 졌다고 한다.
/**
GoF Design Patterns에서는 공유될 필요가 없는 객체에 대해서도 이렇게 UnsharedConcreteFlyweight 클래스
를 제공하고 있지만, 개인적으로는 공유될 필요가 없는데이터를 들고 있다면 굳이 Flyweight 인터페이스를 이
용하여 구현 할 필요성을 못 느끼고 있다.
*/
* FlyweightFactory
- Flyweight 객체를 생성하고 관리한다. 클라이언트가 팩토리에게 Flyweight객체를 요구하면 존재하는 인스턴스
를 제공하거나, 존재 하지 않는다면 새로 생성하여 제공 해주어야 한다.
구현
1. 본질적으로 변하지 않는 상태와 각 상황에 따라서 변할 수 있는 부가적 상태를 구분하여 Flyweight에는 본질적 상태에 대한 정보만 저장 하여야 한다.
2. 공유객체는 Factory를 통해서 생성하도록 한다. 클라이언트는 공유객체의 생성을 요청 할 수만 있을뿐 직접적으로 생성에 관여 해서는 안된다.
결과
* 공유 객체의 생성을 요청, 생성, 사용 하는 과정에서 실행 시간을 손해 볼 수 있다. 이는 저장 공간과 상충 관계를 갖는다.
Ref.
Flyweight Pattern : http://blog.naver.com/imzhoon?Redirect=Log&logNo=40039189043
자바로 배우는 디자인 패턴
GoF Design Patterns
Headfirst Design Pattern
