Los patrones de diseño son herramientas. Al igual que las herramientas, hay dos formas de usarlas: la forma correcta y la forma incorrecta. Por ejemplo, si te doy un destornillador y un clavo y te pido que juntes dos trozos de madera, deberías pedirme un martillo. Los martillos se usan para clavos, mientras que los destornilladores se usan para tornillos.
Muy a menudo, un patrón de diseño se anuncia como One True Way, que a menudo solo es cierto cuando surgen problemas particulares. Los desarrolladores junior a menudo son como niños cuando encuentran algo nuevo para jugar; quieren aplicar ese patrón de diseño a todo . Y no hay nada intrínsecamente incorrecto en esto, siempre que aprendan que el Patrón A se aplica al Problema B, y que el Patrón C se aplica al Problema D. Así como no usa un destornillador para clavar clavos, no usa un patrón solo porque existe; utiliza el patrón porque es la mejor herramienta (conocida) para el trabajo.
La otra cara de los patrones son anti-patrones. Cosas que han demostrado ser malas una y otra vez, generalmente en términos de tiempo de ejecución o memoria. Sin embargo, tanto los patrones como los anti-patrones no son buenos para el desarrollador que no entiende por qué existen. A los desarrolladores les gusta pensar que lo que están haciendo es nuevo e inventivo, pero la mayoría de las veces no lo son. Probablemente se ha pensado antes. Las personas anteriores a ellos han creado los patrones debido a la experiencia.
Por supuesto, los desarrolladores junior a menudo parecen encontrar nuevas formas de hacer cosas viejas, y a veces esas formas son mejores. Sin embargo, con demasiada frecuencia termina siendo un caso del efecto Dunning-Kruger; el desarrollador sabe lo suficiente para crear un programa funcional, pero no entiende sus propias limitaciones. La única forma de superar esto parece ser a través de la experiencia, tanto positiva como negativa. Ignoran los patrones porque se creen superiores, pero no saben que, en realidad, 10.000 desarrolladores ya han usado un diseño específico y luego lo han descartado porque en realidad era malo.
Agile favorece "hacer las cosas de manera responsable" en lo que respecta a un rápido ajuste a las necesidades cambiantes de los clientes. No favorece los patrones de diseño ni los desprecia. Si un patrón es el método más rápido y confiable, entonces el desarrollador debe usarlo. Si un patrón en particular costara más tiempo que simplemente "lograrlo", es probable que esté bien usar algo que no es un patrón (asumiendo, por supuesto, que el rendimiento no está muy degradado, etc.). Si no se puede encontrar un patrón conocido, se prefiere el diseño propio antes que decirle a un cliente que "no". Los clientes, especialmente los clientes que pagan, generalmente tienen razón.
Cualquiera que afirme que los patrones son el Camino, o que los patrones son La Perdición de la Existencia, está equivocado. Los patrones son herramientas, destinadas a aplicarse a situaciones específicas, y tienen diferentes grados de éxito en función de las circunstancias. Esta es una Verdad, una que no depende de si eligió MVC o no, si usa Objetos de Transferencia de Datos, o no, etc. Lo que importa es implementar el código en un marco de tiempo razonablemente corto, que funcione razonablemente bien para los usuarios, y está razonablemente libre de errores lógicos.
Por lo general, , los patrones permitirán una forma coherente de diseño y tendrán un mejor rendimiento que ignorar todos los patrones en favor de escribir ideas 100% originales, pero no se pueden evitar todos los patrones. Por ejemplo, si y = x + 5, ¿realmente vas a escribir y = x + (5 * 3 + 15/3) / 4, solo para evitar el patrón de escritura x + 5? No tu no eres. Vas a escribir y = x + 5, y pasarás al siguiente problema.
La gente usa patrones todos los días y está bien . Lo que más importa es tener un código que sea lógicamente funcional, que rara vez se bloquee y que sea fácil de usar. Nada más importa más que eso.