Patrones de Diseño
En las siguientes líneas hablaremos acerca de los patrones de diseño. Tocaremos diferentes puntos de manera breve y sencilla como:
- ¿Qué son los patrones de diseño?
- Historia de los patrones.
- Clasificación o tipos de patrones.
- Catálogo de los mismos.
Los temas mencionados nos ayudan con problemas específicos que seguramente hemos resuelto muchas veces de diferentes maneras y usarlos dentro de nuestro software nos pueden ahorrar algunos dolores de cabeza.
¿Qué es un patrón de diseño?
Los patrones de diseño son una herramienta muy eficaz para escribir código de calidad. Sirven para resolver problemas comunes y recurrentes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Se adaptan de acuerdo a contextos específicos, identifican problemas en el sistema y proporcionan alternativas generales.
Estas son soluciones probadas, fáciles de mantener y se ajustan a las diferentes necesidades dentro de nuestro desarrollo. Dado que existe una gran probabilidad de que alguien se haya enfrentado a un problema muy similar al nuestro, se podría modelar de la misma manera o similar; es decir, se puede hacer una estructura de las clases para la solución de problemas.
No se puede elegir un patrón y copiarlo en nuestra aplicación como si se tratara de una librería preparada. Más que una porción específica de código, es un concepto general para resolver un problema particular.
Para que la solución sea considerada un patrón debe poseer ciertas características, como haber comprobado su efectividad resolviendo problemas similares y ser reutilizable.
Historia
El concepto de los patrones de diseño se le atribuye a un profesor de arquitectura: Christopher Alexander. En su libro “El lenguaje de patrones”, habla de un “lenguaje” para diseñar un entorno urbano, con los patrones como sus unidades. “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”.
En 1987, Ward Cunningham y Kent Beck, sobrepasados por el pobre entrenamiento que recibían los nuevos programadores en orientación a objetos, se preguntaban cómo capturar las buenas ideas para transmitirlas a los programadores recién instruidos en herencia y polimorfismo. Se dieron cuenta del paralelo que existía en la declaración de Alexander.
No obstante, no fue hasta principios de la década de los 90s cuando la idea fue recogida por cuatro autores: Erich Gamma, John Vlissides, Ralph Johnson y Richard Helm. En 1994, publicaron el libro “Patrones de diseño: elementos reusables de software orientado a objetos”, en el que aplicaron el concepto a la programación. Presentan 23 patrones que resuelven problemas del diseño orientado a objetos. Fue un éxito, pero con tantos autores la gente empezó a llamarlo “el libro de la ‘Gang of Four’ (banda de los cuatro)”, lo que pronto se abrevió a “el libro GoF”.
Desde entonces se han descubierto decenas de nuevos patrones orientados a objetos. La “metodología del patrón” se hizo muy popular en otros campos de la programación, por lo que hoy en día existen muchos otros patrones no relacionados con el diseño orientado a objetos, pero el principal catálogo de patrones es el del ya mencionado libro de GoF.
Tipos de patrones
Los patrones de diseño se clasifican en tres tipos. Varían en su complejidad, nivel de detalle y escala aplicable al sistema completo que se diseña. Tenemos las siguientes categorías: patrones creacionales, patrones estructurales y patrones de comportamiento.
Patrones creacionales
Proveen soluciones para la creación de objetos, permitiéndonos hacer un sistema independiente de cómo sus objetos son creados incrementan la flexibilidad y la reutilización del código existente.
Factory Method: proporciona una interfaz para crear objetos en una superclase, mientras permite a las subclases alterar el tipo de objetos generados.
Abstract Factory: produce familias de objetos relacionados sin especificar sus clases concretas.
Builder: construye objetos complejos paso a paso. El patrón nos permite producir distintos tipos y representaciones de un objeto empleando el mismo código de construcción.
Prototype: copia objetos existentes sin que el código dependa de sus clases.
Singleton: se asegura de que una clase tenga una única instancia, a la vez que proporciona un punto de acceso global a dicha instancia.
Patrones estructurales
Explican cómo ensamblar objetos y clases más grandes a la vez que se mantiene la flexibilidad y la eficiencia de la estructura, estas estructuras permitirán que se agreguen nuevas funcionalidades.
Adapter: facilita la colaboración entre objetos con interfaces incompatibles.
Bridge: divide una clase grande o un grupo de clases estrechamente relacionadas en dos jerarquías separadas (abstracción e implementación) que pueden desarrollarse independientemente la una de la otra.
Composite: compone objetos en estructuras de árbol y trabajar con esas estructuras como si fueran objetos individuales.
Decorator: añade funcionalidades a objetos al colocarlos dentro de objetos encapsuladores especiales.
Facade: proporciona una interfaz simplificada a una biblioteca, un framework o cualquier otro grupo complejo de clases.
Flyweight: mantiene más objetos dentro de la cantidad disponible de RAM, compartiendo las partes comunes del estado entre varios objetos en lugar de mantener toda la información en cada objeto.
Proxy: proporciona un sustituto o marcador de posición para otro objeto. Un proxy controla el acceso al objeto original, permitiéndote hacer algo antes o después de que la solicitud llegue al original.
Patrones de comportamiento:
Se encargan de una comunicación efectiva y la asignación de responsabilidades entre objetos.
Chain of Responsibility: pasa solicitudes a lo largo de una cadena de manejadores. Al recibir una solicitud, cada manejador decide si la procesa o si la pasa al siguiente de la cadena.
Command: convierte una solicitud en un objeto independiente que contiene toda su información. Esta transformación permite parametrizar los métodos con diferentes solicitudes, retrasar o poner en cola su ejecución y soportar operaciones que no se pueden realizar.
Iterator: recorre elementos de una colección sin exponer su representación subyacente (lista, pila, árbol, etc.).
Mediator: reduce las dependencias caóticas entre objetos. El patrón restringe las comunicaciones directas entre objetos, forzándolos a colaborar únicamente a través de un objeto mediador.
Memento: guarda y restaura el estado previo de un objeto sin revelar los detalles de su implementación.
Observer: define un mecanismo de suscripción para notificar a varios objetos sobre cualquier evento que le suceda al objeto que están observando.
State: permite que un objeto altere su comportamiento cuando su estado interno cambia. Parece como si el objeto cambiará su clase.
Strategy: define una familia de algoritmos, coloca cada uno de ellos en una clase separada y hace objetos intercambiables.
Template Method: define el esqueleto de un algoritmo en la superclase, permitiendo que las subclases sobrescriban pasos del algoritmo sin cambiar su estructura.
Visitor: separa algoritmos de los objetos sobre los que operan.
Una de las ventajas del uso de patrones es que reducen el riesgo de generar un mal diseño de código, dado a que conforman un catálogo amplio de problemas y soluciones. Estos proporcionan un vocabulario común entre los desarrolladores y evitan que “reinventemos la rueda”. Existen muchos tipos de patrones de diseño de software que nos permiten crear nuestro código de manera más fácil y con garantía de que funcionen.
Conclusión
Los patrones son excelentes herramientas las cuales nos permiten estandarizar nuestro código y una mejor lectura cuando se trabaja con otras personas, lo cual nos ayuda a descubrir problemas y a mejorar el código. Siempre hay que estudiar el problema antes de decidir qué patrón de diseño usar. Los patrones de diseño mencionados son los del libro “Design Patterns”, pero existe una lista muy variada para resolver otros problemas.
Referencias
1. desgin paterns by Refactoring.Guru.