La pregunta «¿Todavía hay que estudiar patrones de diseño?» aparece con frecuencia en las comunidades de desarrollo.
Unos dicen: «Apréndelos sí o sí; son fundamentales», mientras otros afirman: «En los lenguajes actuales, la mitad ya no hace falta». Ambos tienen parte de razón, y eso lo vuelve más confuso.
En resumen: los patrones de diseño merecen estudiarse. Pero cuando «aplicar un patrón» se convierte en el objetivo, pasa a ser un atajo para estropear el código.
Este artículo analiza, en orden, por qué hacen falta los patrones de diseño y por qué no conviene idealizarlos.
Qué son los patrones de diseño
En pocas palabras, un patrón de diseño es un catálogo de soluciones comprobadas para problemas de diseño recurrentes.
El punto de partida fue 1994, cuando GoF (Gang of Four) recopiló 23 patrones en el libro 『Design Patterns』. Nombres como Singleton, Factory, Observer y Strategy proceden de allí.
Lo importante es que estos patrones no fueron inventados por alguien en un escritorio. Surgieron al observar que, en muchos proyectos, los desarrolladores resolvían problemas similares de formas parecidas y luego les ponían nombre y los organizaban en un catálogo.
Por eso, la esencia de los patrones de diseño se parece más a la «experiencia organizada» que a una «nueva tecnología».
Por qué hacen falta 1 — Un vocabulario común para el equipo
El mayor valor práctico de los patrones de diseño no está en el código, sino en la comunicación.
En vez de explicar «esta clase debe conservar una sola instancia, permitir el acceso global y posponer la inicialización hasta el primer acceso», basta con decir: «Usemos un Singleton».
Piensa en cuánta información contiene un comentario de revisión como «¿No sería mejor el patrón Observer aquí?». Los nombres de patrones son un lenguaje con una compresión extraordinaria.
Sin este vocabulario, lees más despacio las conversaciones del equipo, la documentación técnica y los comentarios del código open source. Esa es también la razón por la que las entrevistas técnicas siguen preguntando por patrones de diseño.
Por qué hacen falta 2 — La clave para leer frameworks
Los frameworks que usamos a diario ya son conjuntos de patrones de diseño.
- El
UITableViewDelegatede iOS usa el patrón Delegate NotificationCentery los publishers de Combine usan el patrón Observer- La composición de
Viewprotocolos de SwiftUI se acerca al patrón Composite URLSession.sharedes un Singleton
Si conoces los patrones, al ver una API de framework por primera vez puedes pensar: «Ah, esta debe ser esa estructura» y leer la intención de diseño al revés. No solo lees la documentación más rápido; también puedes predecir lo que no está documentado.
Por qué hacen falta 3 — Reutilizar soluciones comprobadas
Resolver el mismo problema desde cero y partir de soluciones perfeccionadas durante décadas son puntos de partida muy distintos.
Por ejemplo, el patrón Factory ya ha tratado el problema de «tener dispersa la lógica de creación de objetos y olvidarla cada vez que se modifica», y el patrón Observer, el de «actualizar varias pantallas cada vez que cambia el estado».
Los patrones documentan no solo soluciones, sino también las compensaciones de esas soluciones. Incluso efectos secundarios como «un Singleton dificulta las pruebas porque es estado global» forman parte del patrón. Es como tener un mapa con las minas que pisaron otros desarrolladores.
Entonces, ¿por qué no hay que idealizarlos?
Hasta aquí, los patrones de diseño pueden parecer universales. El problema suele aparecer «justo después» de aprenderlos.
Cuando tienes un martillo, todo parece un clavo
Después de aprender patrones, es fácil querer aplicarlos en todas partes. Es la conocida trampa del martillo de oro (golden hammer).
Aplicar una Abstract Factory al código que lee un único valor de configuración, introducir Strategy en una lógica con dos ramas y dividir en tres interfaces y cuatro implementaciones algo que cabría en una sola clase.
Los patrones se usan para reducir la complejidad, pero en problemas que no son suficientemente complejos, el propio patrón se convierte en nueva complejidad. Si quien ve el código por primera vez debe saltar entre seis archivos para encontrar la lógica real, eso no es diseño: es un laberinto.
Cuando el lenguaje evoluciona, los patrones desaparecen
Los 23 patrones de GoF se organizaron pensando en el C++ y Smalltalk de 1994. Muchos fueron absorbidos por las funciones del lenguaje.
// 1994de la época: patrón Strategy — clases de + implementación de protocolos
protocol SortStrategy {
func sort(_ numbers: [Int]) -> [Int]
}
final class AscendingSort: SortStrategy {
func sort(_ numbers: [Int]) -> [Int] { numbers.sorted(by: <) }
}
// Hoy Swift: una sola clausura logra el mismo objetivo
let sorted = numbers.sorted(by: >)En lenguajes donde las funciones se pueden pasar como valores, la mayoría de los patrones Strategy y Command se reducen a una clausura de una línea. enum de Swift, los tipos por valor y las implementaciones predeterminadas de protocolos también resuelven en la sintaxis problemas que antes requerían patrones.
También puede verse un patrón como «algo que las personas estructuraron para compensar lo que el lenguaje aún no podía hacer». Por eso, memorizar el catálogo como una verdad inmutable produce código que resuelve con técnicas de hace décadas problemas que el lenguaje ya solucionó.
Cuando el patrón se convierte en el objetivo
La señal más peligrosa aparece cuando el debate de diseño empieza por «¿Qué patrón usamos?» en vez de «¿Cómo resolvemos este problema?».
Un patrón se parece más a un destino al que llegas mientras resuelves un problema que a un punto de partida. La literatura sobre refactorización aconseja no introducir patrones desde el principio, sino refactorizar hacia ellos cuando el código empiece a ejercer presión en esa dirección.
Entonces, ¿cómo conviene usarlos?
En resumen, el punto de equilibrio es el siguiente.
Al aprender, mira primero el problema y no la solución. Debes recordar «en qué situaciones» aparece cada patrón para poder evitarlo cuando no estés en ellas. La mitad de estudiar patrones consiste en saber «cuándo no usarlos».
Al aplicarlos, parte del código más sencillo. Cuando haya duplicación tres veces, llegue una solicitud de cambio real y la estructura actual empiece a pesar, aún estarás a tiempo de refactorizar hacia un patrón. Comprar complejidad hoy por flexibilidad futura suele ser un mal negocio.
Al leer, aprovéchalos activamente. Al leer código ajeno, frameworks u open source, conocer patrones solo aporta beneficios. El riesgo de idealizarlos aparece «al usarlos», no «al leerlos».
Resumen
- Los patrones de diseño son un catálogo de soluciones comprobadas para problemas de diseño recurrentes: fruto de la observación, no de la invención.
- Por qué hacen falta: el vocabulario común del equipo, la clave para leer el diseño de frameworks y soluciones comprobadas con sus compensaciones documentadas.
- Por qué no idealizarlos: aplicarlos a problemas simples convierte el patrón en complejidad (el martillo de oro); muchos desaparecen con la evolución del lenguaje; y si el patrón se vuelve el objetivo, el diseño queda invertido.
- Regla práctica: parte del problema y de un código sencillo; refactoriza hacia un patrón cuando aparezca presión. Al leer, aprovéchalos sin reservas.