Siempre defendi los patrones de diseño. Para mi programar sin patrones de diseño es como querer ser mecánico de autos, sin haber hecho cursos al respecto. Que quiero decir ? Es posible que logres arreglar el auto, pero seguramente no será la mejor solución o serán soluciones fruto de la intuición y la experiencia en ese modelo ( a veces esto es mejor, pero estamos hablando de adivinar soluciones, intuir soluciones, vs entender el diagnostico y resolverlo basado en conceptos adquiridos).
Claramente con cosas nuevas te encontraras con nuevas situaciones las cuales quizás por aplicar soluciones ya vistas hagas entrar un circulo en un cuadrado, pero a la larga tendrás otros problemas. ( El que tuvo autos usados , donde mecánicos de la experiencia se los han arreglado.. sabe de lo que hablo ).
Los patrones te dan eso; que puedas pensar varios tipos de soluciones al respecto y encontrar de acuerdo a tu conocimiento del contexto, la llave, el destornillador adecuada que mejor convenga.
Espera un poquito; mi titulo dice "Pensar en patrones esta mal al inicio de un problema", como es entonces ? Por que la contradicción ?
No hay contradicción si sos un desarrollador TDD. Cuando arrancas un problema bajo el concepto "red, green, refactor" , tu único objetivo es lograr que la suites de problemas a los que pensás resolver estarán ok en la medida que vos puedas pasar de red a green, sin pre conceptos y sin arbitrariedades y , por sobre todas las cosas sin " por las dudas ". Tu única meta es que los test pasen.
OK. Es por eso que concluyo que pensar en patrones antes de implementar los test te sesgan a escenarios donde quizás estas haciendo por las dudas, entonces estas desarrollando cosas que quizás solucionen problemas que nunca ocurran, ó abriras puertas a escenarios que nunca se den; esto implica perdida de tiempo
Creo que el buen criterio seria aplicar la idea de patrones una vez que todos tus test pasan al estado "green", recién ahí empezás a pensar en que patron se adecua a la solución implementada. En ese momento, quizás el momento de la piedra libre a tus cualidades de razonamiento ( la parte divertida ) dadas las situaciones de problemas que investigaste para plantear tus escenarios de test, entendés por que será mejor un command, que un strategy ó un state pattern. Por que claramente usarías una factory o un builder, ó por que recién ahora conviene un mediator en lugar de un Facade, como presupusiste.
Buscar ser un eficiente TDD developer te llevará sin duda a ser un mejor Pattern oriented developer. Pensar para que vas usar el auto , te lleva ver como lo diseñas. Pensar algo que sirve por default para todas las soluciones no solo te cierra posibles contextos en los cuales quedes desajustado, si no que te lleve a implementar complejidades innecesarias que solamente te lleven a test innecesarios; Esta es la situación donde los que "desacreditan" TDD tienen razón para protestar por la productividad. Si hacemos cosas de mas , claramente le robamos tiempo a las cosas que si son necesarias.
La economía de recursos no implica malos diseños , implica Mejores diseños, es por eso que resolver los problemas con las ideas y herramientas adecuadas depende mucho de como se implemente mas alla de saber, ahora comparando con el ajedrez, cómo mover las piezas.
