Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Flyweight 패턴은 Structural 패턴에 속한다.  

이 패턴을 적용해야 하는 상황은 아래와 같다.

1. 애플리케이션에서 생성되는 객체의 수가 엄청나게 클 때

2. 객체의 생성이 메모리에 많은 부하를 주고 시간이 오래 걸릴 때

좀 더 자세히 이 패턴에 대해서 짚어보자.

Flyweight Pattern Structure

 
The following object diagram shows how flyweights are shared:

패턴의 목적 ( Intent ) : 

Use sharing to support large numbers of fine-grained objects efficiently.

플라이웨이트 패턴은 많은 수의 객체를 효율적으로 제공하기위해 공유개념을 이용한다.  

패턴이 나오게 된 동기 ( Motivation ) :

 Flyweight 패턴은 동일한 클래스에 대한 많은 객체를 생성해야 할 때 사용될 수 있다. 각 객체마다 메모리와 공간을 잡아먹기 때문에 사양이 낮은 컴퓨터나 모바일 기기에서는 메모리와 공간에 대한 제약을 피할 수 없는데 만약 내가 만드는 프로그램이 엄청 많은 객체를 생성한다면 이 패턴을 공부해서 적용해보기 바란다. 플라이웨이트 패턴은 객체를 공유함으로써 메모리 부하를 줄일 수 있기 때문이다. 

유용성 ( Applicability ) :

The Flyweight pattern's effectiveness depends heavily on how and where it's used.

플라이웨이트 패턴의 효과는 어떻게 어디서 사용되느냐에 따라 심하게 좌지우지 된다.

Apply the Flyweight pattern when all of the following are true:

아래 내용과 모두 맞아 떨어지는 상황에서만 이 패턴을 적용하면 된다.

· An application uses a large number of objects.

애플리케이션이 정말 많은 객체를 사용할 때
· Storage costs are high because of the sheer quantity of objects.

저장비용이 높을 때( 객체 개수가 많아서 )
· Most object state can be made extrinsic.

대부분의 객체의 상태가 부대적인 것일 때
· Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed.

부대적인 상태가 제거됐을 때에는 적은 수의 공유 객체로 많은 수의 객체를 대체할 수 있을 때
· The application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.

애플리케이션이 객체의 identity에 의존적이지 않을 때 

등장 인물 ( Participants ) :

· Flyweight
o declares an interface through which flyweights can receive and act
on extrinsic state.
· ConcreteFlyweight (Character)
o implements the Flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object must be sharable. Any state it stores must be intrinsic; that is, it must be independent of the ConcreteFlyweight object's context.
· UnsharedConcreteFlyweight (Row, Column)
o not all Flyweight subclasses need to be shared. The Flyweight interface enables sharing; it doesn't enforce it. It's common for
UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure
(as the Row and Column classes have).
· FlyweightFactory
o creates and manages flyweight objects.
o ensures that flyweights are shared properly. When a client requests a flyweight, the FlyweightFactory object supplies an existing
instance or creates one, if none exists.  

· Client
o maintains a reference to flyweight(s).
o computes or stores the extrinsic state of flyweight(s).

원리 ( Collaborations ) :

· State that a flyweight needs to function must be characterized as either intrinsic or extrinsic. Intrinsic state is stored in the ConcreteFlyweight object; extrinsic state is stored or computed by Client objects. Clients pass this state to the flyweight when they invoke its operations.
· Clients should not instantiate ConcreteFlyweights directly. Clients must obtain ConcreteFlyweight objects exclusively from the FlyweightFactory object to ensure they are shared properly.

패턴 사용의 장단점 ( Consequences ): 

 
Flyweights may introduce run-time costs associated with transferring, finding, and/or computing extrinsic state, especially if it was formerly stored as intrinsic state. However, such costs are offset by space savings, which increase as more
flyweights are shared.

Storage savings are a function of several factors:

· the reduction in the total number of instances that comes from sharing
· the amount of intrinsic state per object
· whether extrinsic state is computed or stored.

The more flyweights are shared, the greater the storage savings. The savings increase with the amount of shared state. The greatest savings occur when the objects use substantial quantities of both intrinsic and extrinsic state, and the extrinsic state can be computed rather than stored. Then you save on storage in two ways: Sharing reduces the cost of intrinsic state, and you trade extrinsic state for computation time.
The Flyweight pattern is often combined with the Composite (183) pattern to represent a hierarchical structure as a graph with shared leaf nodes. A consequence of sharing is that flyweight leaf nodes cannot store a pointer to their parent. Rather, the parent pointer is passed to the flyweight as part of its extrinsic state. This has a major impact on how the objects in the hierarchy  communicate with each other. 

관련 패턴들 : 

The Flyweight pattern is often combined with the Composite pattern to implement a logically hierarchical structure in terms of a directed-acyclic graph with shared leaf nodes.

It's often best to implement State and Strategy objects as flyweights. 

추가 정보 :   

• Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
• Flyweight is often combined with Composite to implement shared leaf nodes.
• Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight.
• Flyweight explains when and how State objects can be shared.
• Flyweight pattern introduces complexity and if number of shared objects are huge then there is a trade of between memory and time, so we need to use it judiciously based on our requirements.
• Flyweight pattern implementation is not useful when the number of intrinsic properties of Object is huge, making implementation of Factory class complex.

출처 :  http://sourcemaking.com/design_patterns/flyweight

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )  

http://www.journaldev.com/1562/flyweight-pattern-in-java-example-tutorial