Un patrón de diseño es una solución general y reutilizable a un problema que aparece una y otra vez al diseñar software orientado a objetos. El origen del término, tal y como se usa hoy en programación, viene del libro de 1994 "Design Patterns: Elements of Reusable Object-Oriented Software", escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides —conocidos colectivamente como la "Gang of Four"—, que documentó 23 patrones que los autores habían visto aparecer repetidamente en software bien diseñado.
Qué es (y qué no es) un patrón
Un patrón no es un fragmento de código listo para copiar y pegar, es más parecido a un plano: describe la forma general de una solución y las relaciones entre sus piezas, pero la implementación concreta depende del lenguaje y del problema específico. Confundir un patrón con una receta exacta es lo que lleva a aplicarlo mal, forzando un problema real para que encaje en una plantilla en vez de adaptar la plantilla al problema.
Las tres familias principales
Los 23 patrones originales se agrupan en tres categorías. Los creacionales se ocupan de cómo se crean los objetos sin acoplar el código a clases concretas —Factory Method y Singleton son los más conocidos—. Los estructurales se ocupan de cómo se combinan clases y objetos para formar estructuras más grandes sin duplicar código —Adapter y Decorator son ejemplos habituales—. Y los de comportamiento se ocupan de cómo se comunican y reparten responsabilidades los objetos entre sí —Observer y Strategy aparecen constantemente en código real, muchas veces sin que quien lo escribió supiera que tenían nombre—.
El riesgo de forzarlos
El error más común no es desconocer los patrones, es aplicarlos porque se conocen, no porque el problema los necesite. Envolver una función simple en tres capas de abstracción "por si acaso" hace falta más flexibilidad en el futuro no es clean code, es sobreingeniería, y con el tiempo se convierte en deuda técnica tan real como la de no aplicar ningún patrón. Muchos patrones existen, de hecho, para servir a los principios SOLID en un caso concreto —Strategy, por ejemplo, es una forma directa de aplicar el principio Open/Closed—, así que tiene más sentido aprenderlos como herramientas para esos principios que como una lista a memorizar y aplicar por norma.
Cuándo sí tiene sentido usarlos
Un patrón gana su sitio cuando el problema que resuelve ya se repitió más de una vez en el proyecto, o cuando se anticipa con evidencia real —no solo intuición— que una parte del sistema va a necesitar variarse de formas conocidas. La señal más fiable de que hace falta un patrón no es leer sobre él, es notar que ya se está escribiendo el mismo tipo de código una y otra vez con pequeñas variaciones.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!