Flyweight

Flyweight
Información sobre la plantilla
Flyweith.jpg
Concepto:Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.

Flyweight: El patrón Flyweight (u objeto ligero) sirve para eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen información idéntica.

Clasificación

Estructura, a nivel de objetos.

Propósito

Mejorar la eficiencia a la hora de mantener una gran cantidad de objetos “de grano fino”, usando la idea de la compartición. Un “PesoMosca” es un objeto compartido que puede ser usado en diferentes contextos simultáneamente, de forma transparente, indistinguible.

El concepto clave aquí es la distinción entre el ESTADO INTRÍNSECO (información independiente del contexto del objeto, almacenada en el mismo y que favorece su compartición) y el estado extrínseco (información que depende y varía con el contexto donde se use el objeto, no puede ser compartida y se la proporciona el cliente que lo usa, a través de la fábrica) del objeto compartido.

Motivo

Algunas aplicaciones pueden usar objetos durante todo su diseño, pero esto puede ocasionar implementaciones costosas. La mayoría de editores de documentos tienen formato de texto y facilidades de edición que son implementados por alguna extensión.

Típicamente editores de documento orientados a objetos usan objetos para representar elementos embebidos como tablas o figuras, así también utilizan objetos para representar cada carácter, manejar el editor de esta manera ofrece flexibilidad al sistema, pues pueden ser dibujados y formateados uniformemente, con figuras y tablas, pero la desventaja es que un documento de texto puede tener miles de caracteres, por eso te-ner un objeto por carácter implica un gran costo debido a la memoria que puede consumir.

Flyweight permite compartir objetos ligeros, para hacer el programa más liviano. Los objetos pueden compartir estados intrínsecos que no dependen del contexto, pero no pueden compartir los estados extrínsecos que dependen del contexto.


Aplicabilidad

La efectividad de este patrón depende de cómo y cuándo es utilizado, por eso es importante implementarlo siempre que todas las siguientes situaciones se cumplan:

  • Una aplicación usa un gran número de objetos.
  • El coste de almacenamiento es alto debido al excesivo número de objetos.
  • La gran mayoría de los estados de los objetos puede hacerse extrínseco.
  • Al separar el estado extrínseco, muchos grupos de objetos pueden reemplazarse por unos pocos objetos compartidos.
  • La aplicación no depende de la identi-dad de los objetos, pues el patrón se basa en el compartimento de objetos.

Ventajas e inconvenientes

Ventajas

  • Mejora en la eficiencia, sobre todo en relación con el ahorro en el almacenamiento, que aumenta paralelamente con la compartición de objetos y es función de:
(a) la reducción en el número total de instancias.
(b) la cantidad de estado intrínseco por objeto.
(c) si el estado extrínseco es computado (calculado) o almacenado. 

Inconvenientes

  • Se introducen costes en tiempo de ejecución asociados a las transferencias, búsquedas y/o computación del estado extrínseco (y su almacenamiento).

Participantes

  • Flyweight: Declara una interfaz por medio de la cual flyweights puede recibir e in-terpretar estados extrínsecos.
  • ConcreteFlyweight: implementa la interfaz Flyweight y almacena estados intrín-secos, si existen. Los ConcreteFlyweight deben ser compartibles, cualquier estado de este debe ser intrínseco.
  • UnsharedConcreteFlyweight: No todos los flyweight tienen que ser compartidos, la interfaz Flyweight habilita el compartimiento pero no lo fuerza. Es común que los objetos UnsharedConcreteFlyweight tengan objetos ConcreteFlyweight como hijos en algún nivel de la estructura del flyweight.
  • FlyweightFactory: Crea y maneja objetos flyweight, se asegura que flyweights se-an compartidos adecuadamente. Cuando el cliente hace la petición de flyweight la FlyweightFactory proporciona una ins-tancia existente, y si no existe crea una.
  • Client: Mantiene una referencia a Flyweight. Almacena o calcula los estados extrínsicos de los flyweights.

Relacionado con

  • Peso Mosca se combina habitualmente con Composición para implementar estructuras jerárquicas lógicas en términos de grafos acíclicos dirigidos con nodos hoja compartidos. Como consecuencia de la compartición un nodo hoja no puede tener un puntero a su padre (ambigüedad, pues tiene varios), si no que éste se le pasa como parte del estado extrínseco.
  • Suele ser muy ventajoso implementar Estado y Estrategia como Pesos Mosca.

Otros aspectos de interés

  • Eliminar el “EstadoExtrínseco” de los objetos compartidos puede no reducir los costes de almacenamiento si resultan ser tan variados como los propios objetos.
  • La “FábricaDePesosMosca” es quien gestiona y controla las clases compartibles, permitiendo a los clientes el acceso (indirecto) a las mismas. Suele usar almacenamiento asociativo para facilitar a los clientes el acceso a los objetos compartidos de su interés (si el número de estos es grande y/o variable se pueden necesitar técnicas de cuenta de referencias o recolección de basura para eliminarlos y recuperar el espacio ocupado).
  • Los “PesosMoscaConcretosNoCompartibles” en una jerarquía recursiva pueden tener hijos que sí sean para compartir. Además tenerlos inmersos en dicha jerarquía recursiva, junto a los que si se comparten, puede facilitar en el futuro hacerlos también a ellos compartibles, si se considera oportuno o necesario.
  • El “Cliente” proporciona a las clases compartibles el “EstadoExtrínseco” que les falta, pero siempre a través de la “FábricaDePesosMosca”, NUNCA nunca directamente.

Ejemplo de aplicación

En un editor de documentos podemos tener una jerarquía recursiva de elementos gráficos, tales como filas, columnas, caracteres, etc... algunos de los cuales tendrá sentido hacer compartibles, por motivos de eficiencia. Tal es el caso de los caracteres. Si por cada carácter del documento creamos un objeto los problemas de almacenamiento aparecerán de inmediato, mientras que éstos se resolverán fácilmente si sólo se crea un objeto por cada tipo distinto de carácter (256, en ASCII), compartible por cada aparición de los mismos en el texto, en diferentes posiciones (este sería su estado extrínseco).

Fuentes

  • Patrones del "Gang of Four". Unidad Docente de Ingeniería del Software Facultad de informática - Universidad Politécnica de Madrid
  • DesingPatterns.chm.
  • [1]
  • [2]
  • [3]