Diagrama UML

IFlyweight: declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados no compartidos.

ConcreteFlyweight:  declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados no compartidos.

UnshareConcreteFlyweight: no todas las subclases de Flyweight tienen por qué ser compartidas. La interfaz Flyweight permite que se comparta; no lo fuerza. Es común que los objetos de esta clase tengan hijos de la clase ConcreteFlyweight en algún nivel de su estructura.

FactoryFlyweight: crea y gestiona los objetos flyweight. Garantiza que los objetos flyweight se comparten de forma apropiada. Cuando un cliente solicita unflyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente, o crea una.

Client:   crea y gestiona los objetos flyweight. Garantiza que los objetos flyweight se comparten de forma apropiada. Cuando un cliente solicita un flyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente, o crea una.

Nombre del patrón:  Patrón Flyweight/ Peso Ligero
Clasificación del Patrón:  Estructural
 

Intención:  Reducir el numero de objetos  de muy bajo nivel en un sistema mediante 

Motivación: Para eliminar o reducir la redundancia cuando se tiene gran cantidad de objetos que contienen la misma información. Cuando la memoria es crítica para el rendimiento de la aplicación. La aplicación no depende de la identidad de los objetos.

Ejemplo:

Se requiere utilizar un programa el cual  se le cargara "varios autos" y al pedirle el detalle del mismo, muestre patente, color, dueño. Hay que tener en cuenta que debe ocupa poca memoria ya que es un proyecto masivo.

Solución:

Ejemplo

El patrón Flyweight comparte para soportar un gran número de objetos de manera eficiente. La red pública de conmutadores telefónicos es un ejemplo de este patrón. Hay gran cantidad de recursos tales como generadores de tono de marcado, generadores de llamada y receptores de dígitos que deben ser compartidos entre todos los suscriptores. Un suscriptor no tiene conocimiento de cuantos recursos se encuentran en el pool cuando él o ella levanta el auricular para realizar una llamada. Todo lo que le importa a los suscriptores es que se les proporcione el tono de marcado, que los dígitos sean recibidos y que la llamada sea realizada.

Check list

1.  Asegurarse que la sobrecarga de objeto es un tema que necesita atención y el cliente de la clase es capaz y está dispuesto a absorber la responsabilidad de reajuste.

2.  Dividir la clase de estado de destino en: Estado compartible (intrínseco) y estado no compartible (extrínseco).

3.  Quitar el estado no compartible de los atributos de clase y agregarlo como argumento de llamada a la lista de métodos afectados.

4.  Crear un Factory que pueda almacenar en caché y reutilizar instancias de clases existentes.

5.  El cliente debe usar el Factory en lugar del operador new.

6.  El cliente (o un tercero) debe observar o calcular el estado no compartible y suministrar el estado a través de métodos de clase.