Patrones De Diseño

PATRONES DE DISEÑO.

LOS MOCHIS SIN., 10 NOVIEMBRE 2008

Patrones de diseño o más comúnmente conocidos como "Design Patterns". Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan. Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso.

Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos.

El término “patrón de diseño” no es extremadamente preciso pero sí muy útil. En la forma en la que se suele entender actualmente fue acuñado en Gamma y col. (1994), importante referencia que se suele designar abreviadamente como GoF. Por la manera en que se emplea este concepto en esta referencia básica y en la mayoría de usos posteriores, se refiere a una manera especialmente inteligente y perspicaz de resolver un tipo general de problema.

A pesar de constar el término “diseño” no se suele considerar que se refiera únicamente a la fase de diseño de un programa, es una solución completa que incluye análisis, diseño e implementación. Un “patrón de diseño” no se considera bien especificado hasta que se ha podido plasmar en forma de código en algún lenguaje, pero claramente no es una convención o receta “idiomática”, ligada a un lenguaje concreto, como podría la relacionada con “cómo recorrer de forma eficiente un vector en C empleando aritmética de punteros”, por poner un ejemplo. Sin embargo, en GoF se remarca que un patrón puede serlo, tener sentido identificarlo como tal o no, dependiendo del lenguaje utilizado. En el lenguaje de implementación elegido en GoF, C++, un patrón como

“herencia” no tiene sentido (ya está implícito en el propio lenguaje) mientras que sería una solución general muy adecuada a numerosos problemas si el lenguaje de implementación fuese C, por ejemplo. En un ámbito de problemas y de conceptos más cercano a la Estadística, y que trataremos con mayor detalle más adelante, un patrón de diseño muy común como “objeto función” según la terminología de Eckel(2003) o

“comando” según la terminología de GoF, tiene sentido en Java o en C++, pero no en

Python, donde todo, y en concreto cualquier método o función miembro, es un objeto.

Tampoco hay que confundir “patrón de diseño” con un algoritmo adecuado para resolver un tipo concreto de problema –que, lógicamente, se tendría que implementar de forma distinta según el lenguaje. Un patrón de diseño debe ser una especificación muy general, una especie de invariante que se cumple en problemas de ámbitos diversos y que define una solución general y muy estable.

Lista con los patrones de diseño a objetos más habituales publicados en el libro "Design Patterns ", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro").

Patrones de creación

Abstract Factory.

Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.

La idea detrás del patron Abstract Factory (que en español se traduciría como fabrica abstracta) consiste en la noción de que nuestro programa (o el cliente de una clase que nosotros proporcionamos) trabaja con una serie de productos (como los de una fábrica) que tienen unas determinadas características (por ejemplo tenemos productos embotellados y productos en tetrabrick). Nuestro programa va a utilizar dichos productos realizando una serie de acciones sobre ellos (como meter las botellas en unos camiones y los tetrabricks en otros) sin importarle quien le está suministrando los productos.

Así mismo existen una serie de fábricas que producen esos productos que vamos a tratar, una fábrica fabrica cocacola y otra pepsi pero ambas en botellas de las que nuestro programa trata. Al final, el concepto básico consiste en que a nuestro programa (o cliente) no le importa lo que haya dentro de la botella ni quien lo haya producido mientras sea una botella.

Desde el punto de vista software el ejemplo anterior se traduce en una situación en la que nuestro programa maneja un tipo de objetos con unas características comunes y algunas caracterísiticas propias. Esto en general en software se resuelve mediante el uso de dos características de los lenguajes de programación orientados a objetos, las clases abstractas y los interfaces.

Problema

El patrón de diseño Abstract Factory aborda el problema de la creación de familias de objetos (como por ejemplo iterfaces gráficos) que comparten toda una serie de características comunes en los objetos que componen dichas familias.

Aplicabilidad

El uso de este patrón está recomendado para situaciones en las que tenemos una familia de productos concretos y prevemos la inclusión de distintas familias de productos en un futuro.

Estructura

De esta forma nuestro programa realiza unas ciertas operaciones sobre dichas características comunes sin importarle que otras características tenga el objeto en cuestión. Por otro lado existen distintos productores de dichos objetos. Un ejemplo muy típico en muchos frameworks de programación que sigue este patrón se da en el caso de las familias de interfaces gráficos. Así existen diversas fábricas de interfaces que proporcionan sus propios botones, campos de texto, listas desplegables, etc... Todas ellas basadas en los tipos básicos. Los clientes obtienen una familia y proceden a utilizar los controles usando el tipo abstracto genérico que da soporte.

Ejemplos reales

Familia de comunicaciones

Un caso bastante común es el similar al presentado en el ejemplo de código, es decir, una familia de algoritmos de comunicación por distintos medios que permiten el envio de información entre pares (por ejemplo). De esta forma nuestro programa puede usar comunicación TCP, UDP o cualquier otro protocolo que se nos ocurra sobre un dispositivo no estandar o que no soporte IP.

Interfaces gráficos

Otro caso relativamente común de uso de este patrón se da en la creación de familias de interfaces gráficos en las cuales los elementos (productos) del interfaz se mantienen constantes (por ejemplo labels, botones, cajas de texto ...) pero el dibujado de dichos elementos puede delegarse en distintas familias (por ejemplo QT, GTK, etc) de forma que, en función de la fábrica seleccionada obtenemos unos botones u otros.

Builder.

Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.

Permite a un objeto (fuente) construir un objeto complejo especificando sólo su tipo. El objeto constructor (fuente) se compone de una serie de partes que individualmente van formando el objeto complejo. Así se abstrae el proceso de creación del objeto complejo para que se puedan crear representaciones diferentes con el mismo proceso.

Se nos pueden ocurrir muchos ejemplos para el patrón Builder, vehículos, recetas, electrodomésticos y cualquier cosa que esté compuesta por muchas partes. También se utiliza mucho para crear los objetos del patrón Composite (patrón estructural). El siguiente ejemplo va ensamblando los componentes de un ordenador según el uso que le queramos dar.

El patrón constructor sigue la misma idea que el patrón factoría, pero no se encarga simplemente de devolver una clase, si no de construir una composición de objetos entera, por compleja o sencilla que sea. El caso más habitual es el de construir una interfaz de usuario, pero no se limita únicamente a componentes visuales.

Intención

Separar la construcción de un objeto complejo de su representación de modo que el mismo proceso de construcción pueda crear diferentes representaciones.

Motivación

Los objetos que dependen de un algoritmo tendrán que cambiar cuando el algoritmo cambia. Por lo tanto los algoritmos que estén expuestos a dicho cambio deberían ser separados, permitiendo de esta manera reutilizar algoritmos para crear diferentes representaciones.

El patrón Builder se usa cuando:

• El algoritmo para creación de un objeto complejo debe ser independiente de las partes que conforman el objeto y cómo están ensambladas.

• El proceso de construcción debe permitir diferentes representaciones del objeto que se construye.

Estructura

Consecuencias

1. Permite variar la representación interna de un producto.

2. Permite separar el código de la construcción y la representación.

3. Da control refinado sobre el proceso de construcción.

Factory Method.

Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.

Es una simplificación del Abstract Factory, en la que la clase abstracta

...