Cuando empezamos a programar, lograr que algo funcione una vez ya se siente como un gran paso. Que no marque error, que imprima lo que esperas, que haga lo que le pediste. Pero con el tiempo, algo cambia: ese mismo código empieza a repetirse. Y ahí es cuando copiar y pegar ya no alcanza.
Estás haciendo un pequeño sistema para registrar personas. Nada complejo: solo una función que guarda nombre, correo y edad.
Y al final del registro, quieres mostrar un mensaje amable. Así que lo escribes directo en el código:
print("Gracias por registrarte.")
print("Tu información ha sido guardada.")
print("Bienvenida, Laura.")
Funciona. Se ve bien. Pero luego haces lo mismo para Carlos. Y luego para Sofía. Y para cada persona que se registra. Las mismas tres líneas, una y otra vez. Cambia el nombre, pero todo lo demás se repite.
Hasta que un día decides cambiar el mensaje. Quizá hacerlo más formal. O más corto. Y te das cuenta de que escribiste esas líneas en cinco lugares distintos, y no todos están igual.
Algunos dicen “Gracias por registrarte”, otros “Registro completado”. Algunos usan punto al final, otros no. Ya es un pequeño caos.
Así que haces algo distinto. Tomas ese mensaje y lo conviertes en una función:
def mensaje_bienvenida(nombre):
print("Gracias por registrarte.")
print("Tu información ha sido guardada.")
print(f"Bienvenida, {nombre}.")
Y ahora solo llamas a mensaje_bienvenida("Laura"), mensaje_bienvenida("Carlos"), o a quien sea.
No más repeticiones. No más buscar en cinco lugares. Cambias una vez, y todo se actualiza.
En apariencia, solo moviste unas líneas. Pero en el fondo, algo cambió en tu forma de pensar. Dejaste de copiar lo que funciona y comenzaste a preguntarte cómo debería estar organizado. Ese es el inicio del diseño.
No un cambio técnico, sino una forma distinta de ver el código: no como instrucciones sueltas, sino como un sistema que debe sostenerse con el tiempo.
Diseñar también es reconocer patrones
Diseñar en programación no es solo dibujar pantallas ni hacer diagramas —aunque también lo incluye—, sino tomar decisiones sobre cómo se organiza el código, cómo se conecta una parte con otra, y cómo evitar que todo se rompa cuando algo cambia.
Es escribir hoy pensando en lo que vendrá. Es preparar el terreno para crecer sin desorden.
Y cuando haces eso, empiezan a aparecer ciertas preguntas, una y otra vez:
- ¿Cómo evitar repetir código?
- ¿Cómo cambiar una parte sin afectar las demás?
- ¿Cómo mantener todo ordenado cuando el sistema crece?
Ahí es donde los patrones aparecen.
Un patrón, en general, es una forma que se repite con sentido. Puede ser visual, como los azulejos de una pared. O lógico, como la estructura de una carta o un horario.
Los patrones ayudan a prever, a entender, a decidir. Nos muestran qué esperar, y cómo construir a partir de eso.
En programación ocurre lo mismo: ciertas soluciones se repiten porque funcionan bien. Y cuando esas soluciones se vuelven claras, compartidas y adaptables, se transforman en algo más específico: un patrón de diseño.
Un patrón de diseño no es una receta exacta ni una fórmula rígida.
Es una forma de resolver un problema común, de manera clara, estructurada y reutilizable.
Es experiencia compartida. Una especie de atajo que permite diseñar con más intención y menos improvisación.
Algunos patrones que quizá ya usas
- Hay situaciones donde necesitas una sola cosa en todo el programa. Como una única conexión a una base de datos o una sola configuración compartida. En lugar de crear eso muchas veces, lo haces una vez y lo reutilizas.
Es como tener una llave maestra que abre siempre la misma puerta, sin duplicados.
Esa solución tiene nombre: se conoce como el patrón Singleton. - Supón que tu programa necesita crear distintos tipos de usuarios: administrador, editor, lector. Todos comparten algo, pero cada uno tiene funciones distintas.
Entonces haces una función que, según lo que necesita el sistema, construye el tipo de usuario adecuado.
Es como pedir un café: tú eliges si lo quieres con leche o sin, y la persona detrás de la barra ya sabe cómo prepararlo.
Ese tipo de solución se conoce como el patrón Factory Method. - Supón que estás programando un sistema donde, cada vez que alguien se registra, deben pasar varias cosas: se envía un correo de bienvenida, se guarda un registro en la base de datos y se actualiza una interfaz.
- En lugar de escribir todo eso en una sola función larga, haces que esas otras partes estén atentas. Solo esperan que algo ocurra —el registro— para activarse por separado.
- Es como tocar una campana en una casa: no dices qué debe hacer cada persona, solo avisas que algo pasó. Y cada quien, al oírla, actúa según lo que le corresponde. Ese comportamiento se conoce como el patrón Observer.
Más adelante, esos patrones tienen más profundidad, nombres técnicos y variantes. Pero lo esencial no es memorizarlos, sino entender cuándo aparecen, cómo funcionan y por qué ayudan a que el diseño no se desmorone.
Diseñar es también reconocer
No necesitas conocer todos los nombres ni cada detalle desde el principio. Lo importante es saber que esas formas de resolver problemas existen, que tienen lógica, y que muchas otras personas las han usado antes.
Usarlas no te hace menos creativa ni menos capaz. Al contrario: te conecta con una comunidad que valora pensar, construir y diseñar con propósito.
Quizá ya estás usando patrones sin saberlo. Porque vienen de la práctica.
Y cuando los entiendes, no solo mejoras el código. También te entiendes mejor con otras personas que programan. Porque empiezan a hablar el mismo lenguaje.
Un patrón de diseño no es solo código bonito.
Es una decisión pensada que, cuando el sistema crezca, te va a sostener.
Y eso que hiciste para no repetir, para no duplicar, para pensar mejor…
Eso tiene nombre. Y sí: era diseño.
