¿Los patrones de diseño son generalmente una fuerza para bien o para mal? [cerrado]

He oído argumentar que los patrones de diseño son lo mejor desde el pan rebanado. También he oído argumentar que los patrones de diseño tienden a exacerbar el "Síndrome del segundo sistema", que se usan en exceso y que hacen que sus usuarios piensen que son mejores diseñadores de lo que realmente son.

Tiendo a acercarme al antiguo campamento, pero recientemente he estado viendo diseños en los que casi todas las interacciones se reemplazan con una relación de observación, y todo es un singleton.

Entonces, considerando los beneficios y problemas, ¿los patrones de diseño son generalmente buenos o malos, y por qué?

Los patrones de diseño son un lenguaje , no un consejo para escribir un programa o un contrato. Su uso principal es una explicación a posteriori de cómo se implementó (o se implementará) un componente o un sistema. En lugar de entrar en demasiados detalles, solo puede decir un par de palabras que pueden describir la implementación lo suficientemente bien como para que el oyente comprenda cómo funciona y lo que es importante en ella.

Alex: Hola, ¿cómo se crean los archivos de configuración?

Bob: Son generados por una fábrica, que reside en config.h.

Ahora Alex sabe que la creación de archivos de configuración implica preparaciones no triviales, porque de lo contrario su creación no se incluiría en una fábrica.

Sin embargo, si Bob era un falso con cabeza de patrón, y solo usaba patrones aquí y allá, Alex no podía decir nada sobre la creación de configuraciones, porque Bob usaba la fábrica en todas partes. Esto también conduciría a una complejidad excesiva en el programa.

Entonces, programe primero, luego detecte patrones en su código, no al revés. Así es como se usan efectivamente.

Los patrones de diseño son geniales . Cuando se usan correctamente, hacen que el código sea más fácil de mantener, más fácil de leer y trabajar. Parte de ser un buen programador es saber cuándo detenerse y ver que cualquier refactorización adicional superará los beneficios. Usar patrones de diseño por sí solo no hace que alguien sea un buen programador, pero saber cuándo y dónde usarlos sí. Al igual que con cualquier otra cosa en este mundo, los patrones de diseño pueden llevarse al extremo y ser abusados. Sé que todavía estoy buscando (y lo haré durante mucho tiempo) ese equilibrio perfecto en mi código donde cada patrón de diseño tiene un propósito y encaja perfectamente como una pieza de rompecabezas.

Los patrones de diseño son geniales, si se usan correctamente.

Es útil recordar que la idea de los patrones de diseño se originó en la arquitectura. La arquitectura puede variar enormemente. Sin embargo, hay muchas ideas centrales que están presentes en cualquier edificio. De esta manera, piense en los patrones como bloques de construcción de diseño. Es importante tener en cuenta que no todos los edificios incluyen todos los patrones arquitectónicos posibles.

Digamos que estás diseñando una casa. En lugar de tener la puerta principal abierta a la calle, desea un área protegida antes de entrar a la casa, es decir, una antesala. Esta área se ajustará a un cierto patrón. Es decir, tendrá dos entradas, algunas paredes y probablemente un techo. Tenga en cuenta que el patrón no especifica puertas, ventanas o cuántas paredes. En la mayoría de las implementaciones, habrá dos puertas, cuatro paredes y quizás ventanas. Sin embargo, el patrón describe un área cerrada con dos entradas. Uno conduce a la antesala misma desde el exterior de la casa y el otro conduce al resto de la casa. La clave aquí es que si desea una antesala debe encerrar un área y proporcionar dos entradas a esa área.

Los problemas típicos con los patrones de diseño en la programación son el uso excesivo y la creencia de que son balas de plata para solucionar cualquier problema. No son. Son formas de comunicarse y pensar sobre ideas útiles de programación. Si los fragmentos de sintaxis de un idioma en particular son los ladrillos y el mortero, los patrones describen formas útiles de organizarlos para satisfacer ciertas necesidades.

Considero que los patrones de diseño son más un " consejo " que un contrato inalterable que debe seguirse absolutamente. ¿Por qué? Precisamente por la razón que mencionaste. Seguir un patrón de diseño en todo conduce a un gran desorden de código que anula el propósito de usar un patrón en primer lugar.

Es por eso que odio los sitios como Java Practices . Seguro que algunas de las ideas son buenas, pero luego el autor decidió escribir un programa completo (más un marco) siguiendo cada patrón de diseño que mencionó. El autor también escribió cada artículo con grandes citas aterradoras, haciendo que el lector piense que las prácticas reales de Java son horribles y deben evitarse como la peste.

TL; DR: Use patrones de diseño. Simplemente no abuses de ellos

También configure este hilo en SO. Desde otro punto de vista, los patrones de diseño son código repetitivo para compensar las deficiencias de la metodología utilizada. No soy fanático de celebrar demasiado esas soluciones alternativas.

Prefiero los del medio. Como señaló correctamente el póster, la comprensión de los patrones no lo convierte en un buen desarrollador. Por otro lado, la comprensión del patrón te ayudará a convertirte en un buen desarrollador.

Comprender la relación de los patrones y ver un patrón en un proyecto (mientras está en la etapa de concepción) es lo que lo convertirá en un buen desarrollador.

A menudo se dice que los patrones de diseño proporcionan una solución preparada para problemas de programación. ¿Qué tipo de problemas son? "¿Cómo puedo cambiar el comportamiento de los objetos, pero aislar los cambios del resto del sistema?"

Los patrones GoF son reconocidos por proporcionar ese aislamiento (encapsulación) del resto del sistema, pero a menudo es difícil saber qué parte del sistema recibe variabilidad mediante el uso de sus patrones de diseño. En lugar de seguir el esquema de clasificación que propusieron (creacional, conductual y estructural), tracé las diferencias de los patrones y se me ocurrieron otros dos esquemas para clasificar sus patrones: ciclo de vida y jerarquía de encapsulación de componentes.

Como puede ver en esta tabla para la jerarquía de encapsulación, los patrones de diseño se pueden aplicar en todos los niveles de un componente. ¿Pero tendría sentido? ¿Será necesario que el componente proporcione variación de comportamiento al nivel de encapsulación propuesto, y se usa el patrón apropiado para ese nivel? Si estas preguntas no se responden correctamente, es muy probable que los patrones de diseño se apliquen incorrectamente. El hecho de que se pueda construir un pivote vertical en la cabina de un automóvil no lo convierte en una idea inteligente.

Usando una analogía con el dinero, un patrón de diseño debe considerarse como una solución con un alto costo de capital pero bajos costos operativos. Los patrones de diseño cuestan una fortuna por adelantado en términos de codificación adicional, verbosidad y el peso conceptual de la indirecta adicional que crean. También tienden a bloquear otros aspectos de su diseño. Por ejemplo, usar el método de plantilla te obliga a programar en un estilo muy OO.

Sin embargo, si necesita resolver una gran cantidad de problemas estrechamente relacionados que varían de algunas maneras pequeñas, o si definitivamente va a necesitar modificar un código en gran medida de alguna manera específica en el futuro, los costos iniciales pueden valer la pena porque el diseño los patrones agregan flexibilidad a su código. Las modificaciones o la solución al segundo conjunto de problemas estrechamente relacionados serán mucho más fáciles con patrones que sin ellos.

Ambos campamentos son correctos: son una fuerza para el bien cuando se usan correctamente, una fuerza para el mal si están esparcidos por todo el lugar.

Los patrones de diseño pueden tener la habilidad de atraerlo, pero lo mismo ocurre con la codificación en general. Es fácil dejarse seducir escribiendo la caja de herramientas definitiva: solo debes tener en cuenta a YAGNI para evitar que te desvíes del curso, ten una idea de cuánta estructura necesita la aplicación. En mi opinión, esto es solo para el individuo y una marca de su experiencia / juicio.

Pienso en los cambios de diseño, no en algo que constantemente intentas aplicar a tu código. Para mí se trata principalmente de un lenguaje común para desarrolladores. Es más fácil decir "seguimos un patrón de construcción" que explicar todo una y otra vez.

Actualmente estoy releyendo los patrones de arquitectura de aplicaciones empresariales en este momento, porque me topé con un montón de código que sigue uno de los patrones de ese libro. No creo que se haya elegido intencionalmente seguir uno de los patrones, pero definitivamente ayuda si puedes decir " es un script de transacción " y todos tienen una comprensión clara de lo que eso significa.

Pero me gusta la idea de que puede elegir entre un catálogo de patrones preparado, cuando diseña una nueva funcionalidad o una nueva aplicación. ¿Por qué reinventar todo si hay soluciones comprobadas para ciertos problemas?