Por qué los patrones de diseño suelen sobrar en el software moderno

Fuentes: Design Patterns Suck

Los patrones de diseño, popularizados por el libro de 1994 de la «Banda de los Cuatro» (Gamma, Helm, Johnson y Vlissides), se concibieron como plantillas reutilizables y agnósticas al lenguaje para resolver problemas recurrentes de diseño. Con el tiempo, señala el autor, se han convertido en dogma: se enseñan como soluciones universales y se aplican incluso donde no hacen falta, lo que dispara la sobreingeniería y vuelve ilegibles las bases de código.

El argumento central es que muchos patrones existen solo para compensar carencias de los lenguajes. El Singleton, por ejemplo, exige en Java alrededor de quince líneas de código con constructor privado, instancia estática y método getInstance, mientras que en Scala se reduce a una sola línea (object Logger). Lo mismo ocurre con Factory, Observer o Strategy: en Python, Ruby o Scala, gracias a funciones de primera clase, decoradores, duck typing y constructores flexibles, esos patrones desaparecen o se vuelven triviales.

El autor distingue entre la «filosofía Gosling» (Java, rígida para proteger al desarrollador medio de sí mismo) y la «filosofía Guido» (Python, optimizada para legibilidad y herramientas expresivas). En su experiencia en grandes tecnológicas, ningún equipo usa estos términos en el día a día ni aparecen en entrevistas. El valor real de los patrones, concluye, no es enseñar a escribir buen código, sino servir como vocabulario compartido: una etiqueta corta para describir una idea ya implementada, no una receta que aplicar a ciegas.