flyweight

Patrones Estructurales (V): Patrón Flyweight


Objetivo:

“Compartir una parte común del estado de un objeto para hacer más eficiente la gestión de un número elevado de objetos de grano más fino.”

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Flyweight u “objeto ligero”, a diferencia de algunos de los patrones vistos hasta el momento, no goza de un uso masivo entre la comunidad de ingenieros de software. El motivo no radica en su falta de utilidad o de interés, sino que se centra principalmente en el concepto de rendimiento. A grandes rasgos, se basa en dividir un objeto en dos partes: una parte “común” a un conjunto grande de los objetos de la clase (parte intrínseca), y una parte “privada” que será accesible y modificable únicamente por un objeto en concreto (parte extrínseca).

Un ejemplo simple de Flyweight podría ser el gestor de ventanas del sistema operativo. Un tema de ventanas poseerá atributos como color de fondo, fuente tipográfica, grosor del borde de la ventana, estilo de los botones… Muchos de estos atributos serán comunes a todas las ventanas, por lo que podríamos almacenar toda esta información en un elemento compartido y hacer una llamada a un método para que, haciendo uso de estos atributos comunes y de los parámetros recibidos por el método, se realice una operación que no requiera una instancia exclusiva para ello.

Por ejemplo, realizando una llamada a un método como RenderizarVentana(int x, int y, int ancho, int alto), nuestro objeto Flyweight utilizaría los valores almacenados comunes a todas las ventanas para dibujar una ventana en la posición (x, y) con unas dimensiones (ancho, alto). La instancia de la ventana será única, limitándose a devolver un objeto con las características indicadas. La alternativa simple, como podremos imaginar, sería instanciar un objeto por cada ventana presente en el sistema que almacenara todos estos datos de forma individual más, opcionalmente, valores específicos para la posición y las dimensiones de la ventana. Como siempre ocurre con los patrones de diseño, simplificar una parte del software implicará aumentar la complejidad de otra. En este caso, un diseño más simple se corresponderá con un aumento de consumo de memoria. El límite, nuevamente, se encontrará en el punto de equilibrio que el diseñador estime conveniente.

 

(más…)

Anuncios