En el capítulo de introducción a los patrones de diseño, vimos que los patrones de diseño son soluciones estándar a problemas recurrentes en programación.
Este capítulo orientará el uso de patrones de diseño: como identificarlos y las recomendaciones de uso.
También veremos que los patrones de diseño se agrupan en familias, y agruparemos algunos patrones dentro de su familia correspondiente.
Recursos en la web
Un patrón de diseño es una solución bien conocida a un problema recurrente en un contexto determinado.
En el caso de la POO, la solución al problema se explicita como un conjunto de clases, interfaces y sus relaciones.
Los patrones de diseño, además de proporcionar soluciones a problemas, nos proporcionan, como programadores, un lenguaje común.
Por ejemplo, si un compañero me dice que tiene un problema con su código porque necesita modificar el comportamiento de algunas de sus clase en tiempo de ejecución, y yo conozco la solución, le puedo decir que eche un vistazo al patrón Strategy.
La descripción de un patrón de diseño se hace a través de cuatro elementos fundamentales:
Una implementación en algún lenguaje de programación popular también es de ayuda.
Veamos el caso del patrón de diseño Strategy.
3. La solución
Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
4. Las consecuencias:
Ventajas:
Desventajas
Existe una gran cantidad de patrones de diseño. Algunos de ellos como Strategy son muy recurrentes, otros no lo son tanto.
Para poder trabajar con ellos resulta interesante agruparlos según su propósito, de ahí nacen las familias de patrones de diseño.
Existen tres grandes familias de patrones de diseño: De Creación, Estructurales y De Comportamiento.
Familia de patrones de diseño de Creación.
Una paradoja: No uses el operador new para crear instancias de una clase, ¿cómo las obtengo entonces ?
Con algún patrón de la familia de Creación.
Familia de patrones de diseño de Creación.
Un ejemplo: Supón que estás desarrollando una aplicación para la gestión de clínicas dentales. Los datos de los clientes están en una base de datos, ¿en cual?, ni idea, puede ser MySQL, Oracle, PostgreSQL, Access, etcétera.
Con independencia del gestor, de algún modo obtendré acceso a la base de datos y podré hacer consultas SQL.
Afortunadamente, Java resuelve este problema con la biblioteca jdbc. Independientemente del gestor, yo le pido a un Factory que me devuelva una instancia para conectarme a la base de datos.
¿Y si cambia el gestor?
Me da igual, quien se tiene que preocupar es Factory, yo sólo soy su cliente.
Familia de patrones de diseño Estructurales.
Permiten componer nuevos objetos a partir de objetos ya existentes. Es más flexible que la herencia y la agregación, ya que puede actuar dinámicamente.
Hasta ahora, hemos creado nuevas clases a partir de otras existentes utilizando la herencia y la composición.
Los patrones de diseño Estructurales nos permiten construir clases a partir de otras de un modo más flexible.
Familia de patrones de diseño Estructurales.
Supón, por ejemplo, que estás desarrollando un interfaz de usuario. Creas objetos que representan ventanas, botones, listas, árboles desplegables etcétera.
Ahora tienes la necesidad de añadir barras de desplazamiento a tus elementos gráficos, para poderlas añadir a una ventana, a una lista, etcétera.
Familia de patrones de diseño Estructurales.
Se te pueden ocurrir dos soluciones:
Las dos soluciones son válidas, pero poco flexibles.
Familia de patrones de diseño Estructurales.
Si eliges la primera solución: ¿Qué ocurre si quieres tener una ventana con barras de desplazamiento y un título?
¿Y si quieres barras de desplazamiento, un título y bordes circulares?
¿Y si quieres barras de desplazamiento, bordes circulares pero no título?
Uf!, parece que tengo un explosión de clases.
Familia de patrones de diseño Estructurales.
Si optas por la segunda solución, y creas un atributo en la clase Ventana por cada nueva propiedad que quieras añadir:
Como veremos, en este caso el patrón Decorator nos puede ayudar.
Familia de patrones de diseño de Comportamiento.
En esta familia encontramos patrones que nos permiten cambiar dinámicamente el comportamiento de los objetos o las relaciones entre ellos.
El patrón Strategy pertenece a esta familia. Nos permite cambiar dinámicamente, es decir, en tiempo de ejecución, la implementación de un algoritmo.
| Creación | Estructurales | Comportamiento | |
|---|---|---|---|
| Clase | Factory Method | Adapter | Interpreter |
| Template method | |||
| Objeto | |||
| Abstract Factory | Adapter | Chain of Responsibility | |
| Builder | Bridge | Command | |
| Prototype | Composite | Iterator | |
| Singleton | Decorator | Mediator | |
| Facade | Memento | ||
| Flyweight | Observer | ||
| Proxy | State | ||
| Strategy | |||
| Visitor |
Evitando al máximo el acoplamiento:
No abuses de los patrones de diseño: no intentes usar un patrón de diseño sólo porque lo conoces, te puede complicar más que ayudar.
Los patrones de diseño son una plantilla de soluciones, los puedes usar adaptándolos a tu problema particular. Pero respeta siempre el concepto sobre el que descansa, si tienes que modificar demasiadas cosas de un patrón para que se adapte a tu problema, quizás sea mejor no utilizarlo.
Los patrones de diseño son soluciones muy probadas a problemas recurrentes en POO.
Existe una gran cantidad de patrones de diseño. Para facilitar su uso se agrupan en familias.
Cada familia es un ámbito genérico a la solución. Las principales familias son: De Creación, Estructural y De Comportamiento.
Cuantos más patrones conozcas, antes resolverás los problemas de diseño que pueden aparecer en tu código.
No caigas en la tiranía de su uso si no te resuelve ningún problema de diseño. No utilices un patrón sólo porque lo conoces.