Flyweight

Busca eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen información idéntica, además de lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).
Este patrón quiere evitar el hecho de crear un gran número estados de objeto para representar a un sistema. Permite compartir estados para soportar un gran número de objetos pequeños aumentando la eficiencia en espacio.

Este patrón se debe utilizar cuando:

• 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.

Diagrama UML



Flyweight: declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados no compartidos.
ConcreteFlyweight: implementa la interfaz Flyweight y almacena los estados compartidos, si los hay. Un objeto ConcreteFlyweight debe ser compartible. Cualquier estado que almacene debe ser intrínseco; es decir, debe ser independiente de su contexto.
UnsharedConcreteFlyweight: 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.
FlyweightFactory: 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.
Client: contiene referencias a los flyweights. Calcula o almacena los estados no compartidos de los flyweights.


Ejemplo

Vamos a suponer el siguiente ejemplo: en un colegio tenemos 6 de promedio general.  Se busca saber que porcentaje de desviación con respecto al promedio tiene cada alumno.

A diferencia del resto de los patrones que intentan simplificar al cliente, este patrón lo obliga a conocer detalles de implementación:

 Consecuencias

• Reduce en gran cantidad el peso de los datos en un servidor.
• Consume un poco mas de tiempo para realizar las búsquedas.
• Se complica la codificación lo que puede redundar en el aumento en la aparición de errores.
• El cliente debe tener algún conocimiento de la implementación. Por esto, puede romper con la estructura cliente-servidor.

Temas a tener en cuenta.

Los clientes no deberían instanciar objetos de la clase ConcreteFlyweight directamente. Deben obtenerlos exclusivamente del objeto FlyweightFactory para garantizar que son compartidos apropiadamente.
Este patrón añade confusión a la hora de desarrollar y no está orientado con la teoría de objetos. Pero no debemos desconocer que muchas veces el tema de performance es muy importante. Por ello mismo, debemos utilizarlo con criterio y en los casos donde realmente sea necesario.