Un patrón de diseño es una solución reutilizable para un problema habitual de diseño de software. No es un bloque de código para copiar, sino una forma conocida de organizar clases, objetos y responsabilidades.
Cuando empezamos a programar, nuestra principal preocupación es simplemente “que el código funcione”. Pero a medida que nuestros proyectos crecen, nos damos cuenta de que hacer que funcione no es suficiente. El código se vuelve difícil de mantener, rígido y frágil.
Para eso sirven los patrones de diseño. No son código en sí mismos, sino soluciones probadas a problemas recurrentes en el desarrollo de software.
En este curso vamos a ver los patrones más importantes, explicados «para seres humanos», y cómo implementarlos en C# y C++. Antes de entrar en el código, tenemos que entender qué son exactamente y de dónde vienen.
Qué es un patrón de diseño
Un patrón de diseño es una descripción de una solución a un problema común que ocurre al diseñar software.
Piensa en el diseño de un edificio. Si tienes que crear una puerta para que la gente entre y salga, no reinventas el concepto de «puerta», con sus bisagras y su pomo, cada vez. Usas una solución conocida.
En programación ocurre lo mismo. Un patrón no es una librería ni un framework que puedas importar. Es un concepto, una plantilla de cómo resolver un problema, que nosotros tenemos que adaptar a nuestro código.
Un patrón de diseño es una solución general y reutilizable a un problema que ocurre frecuentemente dentro de un contexto dado en el diseño de software.
El uso de patrones nos ayuda a:
- No reinventar la rueda: usamos soluciones que ya han demostrado ser efectivas.
- Hablar un idioma común: resumimos la intención del diseño con un nombre conocido.
Si te digo «aquí he usado un Singleton para la conexión a la base de datos» o «necesitamos un Observer para la UI», nos entendemos al instante. No necesito explicarte 200 líneas de código; con una palabra he transmitido la intención del diseño.
Un poco de historia: el Gang of Four (GoF)
Aunque parezca algo puramente informático, el concepto original viene de la arquitectura tradicional. En 1977, Christopher Alexander escribió sobre patrones en edificios y ciudades.
Sin embargo, en el mundo del software, la “biblia” llegó en 1994 con el libro “Design Patterns: Elements of Reusable Object-Oriented Software”.
Este libro fue escrito por cuatro autores: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. En nuestra industria, a este grupo se le conoce cariñosamente como el Gang of Four (GoF) o “La banda de los cuatro”.
Ellos recopilaron y describieron 23 patrones de diseño que marcaron la programación orientada a objetos. Los lenguajes han evolucionado mucho desde 1994 y algunos patrones ahora vienen integrados en sus propias construcciones, pero el vocabulario y los problemas que describen siguen siendo útiles.
Estructura de un patrón
Para estudiar un patrón, no basta con ver el código. En este curso, cuando analicemos cada patrón, veremos siempre cuatro puntos clave:
- El problema: qué dolor de cabeza intenta resolver.
- La solución: los elementos que forman el diseño, sus relaciones y responsabilidades (generalmente con un diagrama UML).
- El ejemplo: cómo se implementa en C# y C++.
- Las consecuencias: qué ganamos y, muy importante, qué perdemos al usarlo.
Clasificación de los patrones
El GoF clasificó los patrones en tres grandes categorías, dependiendo de su propósito. Nosotros seguiremos esta misma estructura en el curso:
Se encargan de la instanciación de objetos. Nos ayudan a independizar el sistema de cómo sus objetos son creados, compuestos y representados.
- Ejemplos: Singleton, Factory Method, Builder.
Se ocupan de cómo se componen clases y objetos para formar estructuras más grandes. Ayudan a garantizar que si una parte del sistema cambia, no se rompa todo lo demás.
- Ejemplos: Adapter, Decorator, Facade.
Se centran en la asignación de responsabilidades entre objetos y cómo se comunican entre ellos. No solo describen patrones de objetos o clases, sino también los patrones de comunicación entre ellos.
- Ejemplos: Strategy, Observer, Iterator.
El lado oscuro: cuándo no usar patrones
Esto es quizás lo más importante de este artículo introductorio. Hay una fase por la que pasamos todos los programadores, que yo llamo la “Fiebre de los Patrones”.
Ocurre cuando acabas de leer el libro del GoF (o este curso) y de repente quieres meter patrones en todas partes. Vas a hacer un “Hola Mundo” y le metes una Abstract Factory con un Singleton y un Decorator.
¡Cuidado con la sobreingeniería! Los patrones de diseño añaden complejidad. Si el problema es simple, la solución debe ser simple.
No uses un patrón solo porque «queda elegante». Úsalo porque tienes un problema real que ese patrón resuelve.
El abuso de patrones lleva a un código innecesariamente complejo, difícil de entender y de depurar. Como dice el dicho: “Si tu única herramienta es un martillo, todos los problemas te parecerán clavos”.
A lo largo de este curso vamos a desgranar los patrones uno a uno. Antes de entrar en materia con el código, necesitamos repasar una herramienta visual que usaremos constantemente para explicar su estructura.
