Antes de remangarnos y meternos en faena creo que lo más apropiado es empezar por describir que es un patrón de diseño.

Un patrón de diseño describe un problema que se repite una y otra vez y describe una solución genérica a ese problema, de forma que podamos utilizar dicha solución en todas y cada una de las ocasiones en que afrontemos el problema descrito. En general, un patrón de diseño se compone de cuatro elementos esenciales:

• Nombre del patrón: Nos servirá para identificar el problema y la solución, de forma que podamos referirnos a dicho patrón en conversaciones y/o documentación. Pare una tontería, pero, personalmente, algunas veces hasta que no me describen algo, no lo reconozco por el nombre, así que es más importante de lo que parece.
• Problema: Describe bajo qué circunstancias y en qué momento podremos hacer uso de dicho patrón.
• Solución: Describe los elementos necesarios para el diseño de una solución adaptada a nuestro caso específico. Esta solución en el patrón viene expresada de forma genérica a través de interfaces, objetos y plantillas.
• Consecuencias: Describen como afectará la implementación de este patrón a nuestro diseño, Estas consecuencias nos son muy útiles a la hora de decidir si implementar un patrón o no. Normalmente tienen relación con cómo afectará la aplicación del patrón a nuestro sistema. Pueden tratar por ejemplo sobre flexibilidad, extensibilidad y portabilidad. En general, tratan sobre cómo afecta la implementación del patrón a los requisitos no funcionales de nuestro sistema.

Algo extraído literalmente del libro es que para los autores, un patrón de diseño es “The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” cuya traducción libre viene a decir más o menos lo siguiente “Los patrones de diseño en este libro son descripciones de la comunicación entre objetos y clases adaptada a la resolución de problemas generales de diseño en un contexto particular”. Esto más o menos viene a decir, a mi entender, que los patrones de diseño no se basan en la creación de estructuras de datos concretas que se pueden implementar en una clase como un HashMap o una lista doblemente enlazada, si no que se centran en una solución a un problema concreto en el ámbito de la programación orientada a objetos, proponiendo una solución genérica de clases y relaciones para resolver dicho problema.

En general, en el libro se explican un total de veintitrés patrones de diseño que ellos dividen en tres categorías diferentes.

• Creacionales
  • Abstract Factory: Familias de objetos de productos.
  • Builder: Como se crea un objeto compuesto.
  • Factory Method: Subclase de un objeto instanciado.
  • Prototype: Clase de un objeto que es instanciado.
  • Singleton: Instanciación de un objeto único.
• Estructurales
  • Adapter: Interfaz de un objeto.
  • Bridge: Implementación de un objeto.
  • Composite: Estructura y composición de un objeto.
  • Decorator: Responsabilidades de un objeto sin subclases.
  • Facade: Interfaz de un subsistema.
  • Flyweight: Coste de almacenamiento en objetos.
  • Proxy: Como un objeto es accedido. Su localización.
• Comportamiento
  • Chain of Responsibility: Objeto rellenado en una petición.
  • Command: Cuando y como una petición es rellenada.
  • Interpreter: Gramática e interpretación de un lenguaje.
  • Iterator: Como un elemento agregado es accedido, trasversalmente.
  • Mediator: Cómo y qué objetos interactúan entre sí.
  • Memento: Qué información privada se almacena fuera del objeto y cuando.
  • Observer: Número de objetos que se relacionan, y como mantener actualizadas las relaciones.
  • State: Estado de un objeto.
  • Strategy: Un algoritmo.
  • Template Method: Pasos para un algoritmo.
  • Visitor: Operaciones que pueden ser aplicadas a un objeto sin cambiar su clase.

No os preocupéis si os habéis quedado con cara de “no he entendido nada”, yo me he quedado exactamente igual. Básicamente con lo que os tenéis que quedar en este momento es con que, en el libro, los patrones están divididos en tres clases diferentes y con los nombres de los distintos patrones. Dichos nombres no han sido traducidos ya que a día de hoy, y sea cual sea el ámbito lingüístico en el que se utilicen, se utiliza su denominación inglesa.

Por hoy, vamos a llegar hasta aquí, creo que ya tenemos bastante información para asimilar. No me cabe duda de que aquellos que os dediquéis al desarrollo de software conoceréis algunos de ellos, y otros, aunque no reconoceréis el nombre, os daréis cuanta de que los aplicáis en muchos casos, sobre todo por la proliferación hoy en día de Frameworks que implementan dichos patrones sin que el usuario se percate de ello.

Además, de lo comentado aquí, las primeras páginas del libro tienen un par de secciones sobre cómo seleccionar un patrón de diseño y cómo usar un patrón de diseño, pero básicamente lo único que nombran son pasos lógicos que cualquiera seguiría y/o pasos específicos para la nomenclatura utilizada en el libro. Como no considero importante dichos apartados salvo que se lea el libro, no voy a plasmarlos aquí, si alguien está interesado en profundizar un poco más, os remito al libro. Nos vemos.