Los patrones de diseño son herramientas. Al igual que las herramientas, hay dos formas de usarlas: la correcta y la incorrecta. Por ejemplo, si le doy un destornillador y un clavo, y le pido que una dos piezas de madera, debería pedirme un martillo. Los martillos se usan para clavos, mientras que los destornilladores se usan para tornillos.
Con demasiada frecuencia, 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 malo en ello, siempre y cuando eventualmente aprendan que el Patrón A se aplica al Problema B, y 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; usa el patrón porque es la mejor herramienta (conocida) para el trabajo.
La otra cara de los patrones son los antipatrones. Cosas que han demostrado una y otra vez ser malas, generalmente en términos de tiempo de ejecución o memoria. Sin embargo, tanto los patrones como los antipatrones 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. Es probable que se haya pensado antes. Las personas antes que ellos han creado los patrones debido a la experiencia.
Por supuesto, los desarrolladores junior a menudo parecen encontrar nuevas formas de hacer las 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 comprende 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 creen que son superiores, pero no saben que, en realidad, 10.000 desarrolladores ya han utilizado un diseño específico, y luego lo descartaron porque era realmente malo.
Agile favorece "hacer las cosas de manera responsable" en lo que respecta a adaptarse rápidamente a las necesidades cambiantes del cliente. 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 particular costaría más tiempo que simplemente "hacerlo", usar algo que no sea un patrón probablemente esté bien (suponiendo, por supuesto, que el rendimiento no se vea gravemente degradado, etc.). Si no se puede encontrar ningún patrón conocido, se prefiere diseñar el suyo propio antes que decirle a un cliente "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 sean La Perdición de la Existencia, está equivocado. Los patrones son herramientas destinadas a ser aplicadas a situaciones específicas y tienen diversos grados de éxito según las circunstancias. Esta es una Verdad, una que no depende de si elige MVC o no, si usa Data Transfer Objects, o no, etc. Lo que importa es implementar 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 funcionarán mejor que ignorar todos los patrones a favor de escribir ideas 100% originales, pero no puede evitar todos los patrones. Por ejemplo, si y = x + 5, ¿realmente va 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 eso está bien . Lo que más importa es tener un código que sea lógicamente funcional, raramente se cuelgue y sea fácil de usar. Nada más importa más que eso.