Patrón de diseño

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Breve reseña histórica

En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro The Timeless Way of Building; en él proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad.

En palabras de este autor, "Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez."

Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una forma práctica generaciones de conocimiento arquitectónico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una situación particular o cultural, son algo intermedio. Un patrón define una posible solución correcta para un problema de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones.

Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA-87 titulado Using Pattern Languages for OO Programs.

No obstante, no fue hasta principios de los 90's cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática a partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones diseño comunes.

Objetivos de los patrones

Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error.

Categorías de patrones

Según la escala o nivel de abstracción:

• Patrones de arquitectura: Aquéllos que expresan un esquema organizativo estructural fundamental para sistemas software.
• Patrones de diseño: Aquéllos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software.
• Idiomas: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de Antipatrón de Diseño, que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

Estructuras o plantillas de patrones

Para describir un patrón se utilizan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas. Si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
• Patrones relacionados: Referencias cruzadas con otros patrones.

Relación de principales patrones GoF

Patrones creacionales

• Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
• Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
• Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
• Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
• Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.

Patrones Estructurales

• Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
• Bridge (Puente): Desacopla una abstracción de su implementación.
• Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
• Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
• Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
• Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
• Proxy: Mantiene un representante de un objeto.

Patrones de Comportamiento

• Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
• Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
• Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
• Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
• Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
• Memento (Recuerdo): Permite volver a estados anteriores del sistema.
• Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
• State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
• Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
• Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
• Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Patrones de Sistema

• MVC (Modelo Vista Controlador): Divide un componente o un subsistema en tres partes lógicas: modelo, vista y controlador, facilitando la modificación o personalización de cada parte.
• Session (Sesión): Ofrece una forma de que los servidores de sistemas distribuidos sean capaces de distinguir los clientes, permitiendo que las aplicaciones asocien el estado con la comunicación entre el cliente y el servidor.
• Worker Thread (Thread trabajador): Mejora la productividad y minimiza la latencia media.
• Callback (Retrollamada): Permite que un cliente se registre en un servidor para ciertas operaciones. De esta forma, el servidor puede notificar al cliente cuando la operación ha finalizado.
• Succesive Update (Actualización Sucesiva): Ofrece a los clientes una forma de recibir actualizaciones continuas.
• Router (Encaminador): Desacopla múltiples fuentes de información de los objetos de esa información.
• Transaction (Transacción): Agrupa una colección de métodos de forma que todos ellos finalicen correctamente o fallen de forma colectiva.

Aplicación en ámbitos concretos

Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose lenguajes de patrones y completos catálogos de mano de diversos autores.

En particular son notorios los esfuerzos en los siguientes ámbitos:

• Patrones de interfaces de usuario; esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina (HCI, GUI).

• Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.

• Patrones para la integración de sistemas (EAI), es decir, para la intercomunicación y coordinación de sistemas heterogéneos.

• Patrones de workflow, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales. Véase también BPM .

Bibliografía básica de referencia

• Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)
• A System of Patterns - Buschmann, Meunier, Rohnert, Sommerlad, Stal - Wiley
• UML y Patrones. Introducción al análisis y diseño orientado a objetos - Larman - Prentice Hall
• AntiPatterns. Refactoring Software, Architectures and Projects in Crisis - Brown, Malveau, McCormick Mowbray - Wiley
• Patterns in Java - Mark Grand - Wiley
• EJB Design Patterns - Floyd Marinescu - Wiley
• Head First Design Patterns-O'Relly

Véase también

• Lenguaje de patrón
• Antipatrón de Diseño
• Grasp

Enlaces externos

• Wikimedia Commons alberga una galería multimedia sobre Patrón de diseño.
• Core J2EE Patterns
• Hillside Group Web Pages
• Brad Appleton's Software Patterns Links
• Portland Pattern Repository
• Object::PerlDesignPatterns Módulo Perl en CPAN con métodos específicos de implementación de Patrones de Diseño en lenguaje Perl (en inglés)