¿Cuándo debo usar, y no usar, patrones de diseño? [duplicar]

KISS primero, los patrones más tarde, quizás mucho más tarde. Un patrón es un estado de ánimo, en su mayoría. Nunca intente forzar su código en un patrón específico, en lugar de eso, observe qué patrones comienzan a cristalizar fuera de su código y ayúdelos un poco.

Decidir "ok, voy a escribir un programa que haga X usando el patrón Y" es una receta para el desastre. Podría funcionar para los programas de clase mundial de hello aptos para demostrar las construcciones de código para patrones, pero no mucho más.

Creo que la principal preocupación es que las personas a menudo tienen una tendencia a abusar de los patrones de diseño. Aprenden unos pocos, ven la utilidad de ellos y, sin darse cuenta, convierten esos pocos patrones en una especie de martillo dorado que luego aplican a todo.

La clave no es necesariamente aprender los patrones en sí mismos. La clave es aprender a identificar los escenarios y problemas que los patrones deben abordar. Luego, aplicar el patrón es simplemente una cuestión de usar la herramienta adecuada para el trabajo. Es el trabajo que se debe identificar y comprender antes de poder elegir la herramienta.

Y a veces es una configuración extraña y no hay un patrón de corte y secado para resolverlo de inmediato. En ese punto, se debe prestar más atención al problema que a la solución. Divídalo en problemas de componentes, identifique las áreas del problema que comparten rasgos comunes con los problemas abordados por patrones conocidos, ajuste los patrones para que se ajusten al problema, etc.

Un patrón de diseño funciona mejor cuando se usa como idioma común en su equipo.

Con eso quiero decir, puedes decir algo como "esta clase es un Singleton que implementa nuestro IHairyWidget Abstract Factory " y todos en su equipo entienden lo que eso significa sin tener que entrar en explicaciones detalladas.

Cuando los patrones de diseño fallan es cuando el equipo no los entiende, o cuando se usan en exceso tanto que dejan de hacer que el diseño sea más claro y, en cambio, dificultan la comprensión de lo que realmente está sucediendo.

quizás un poco fuera de tema, pero creo que también cubre tu pregunta: te sugeriría un buen libro Refactoring to Patterns :

  

Este libro introduce la teoría y   practica de patronaje   Refactorizaciones: secuencias de bajo nivel.   refactorizaciones que permiten a los diseñadores   mover con seguridad los diseños a, hacia, o   lejos de las implementaciones de patrones .   Usando código de proyectos del mundo real,   Kerievsky documenta el pensamiento y   pasos que subyacen más de dos docenas   Transformaciones de diseño basadas en patrones.   A lo largo del camino él ofrece ideas sobre   diferencias de patrones y cómo   Implementar patrones en el más simple.   formas posibles.

encontrará ejemplos cuando los patrones de diseño son buenos para usar, así como cuando necesita salir de ellos, no complicar demasiado la aplicación. Y sí, la idea principal es mantener todo lo más simple posible.

La buena respuesta / consejo para su pregunta se encuentra en el artículo ¿Reconoce las 4 Señales de advertencia tempranas del diseño Abuso de patrón? , pero no puedo cargarlo ahora, error 500. No es tan grande, así que solo usé Google Cache para obtenerlo. :

  

Los patrones de diseño de software pueden llevar a una ingeniería excesiva

     

La ingeniería excesiva es el proceso de   por complicar algo En el   Caso de programación, haciendo tu código.   Más complejo y posiblemente más.   Flexible de lo que necesita ser. Más   específicamente, implementando complejos   patrones de diseño de software en simple   problemas.

     

1. Comience simple no complejo

     

¿Cómo sucede esto? Usualmente tu   programa en funcionalidad extra que   Usted anticipa que será utilizado o probado   para ser útil más tarde. Pero que pasa   ¿Si esta necesidad nunca se materializa? En   La mayoría de los casos, el crucero se queda allí.   No se elimina. Entonces el   sistema de software sigue creciendo en   Tamaño y complejidad con todos estos.   características que nunca se están utilizando.

     

2. Tenga cuidado con las señales

     

Esto es quizás diferente para todos   pero sospecho que en la mayoría de los casos, no es   Realmente un esfuerzo consciente. Sino más bien   Es algo producido por el   miedo de ser atrapado con un torpe,   Inelegante, inapropiado o simplemente   puesto, mal diseño; estar atrapado con   algo que simplemente no es flexible   suficiente. Irónicamente, si llegas a la   punto de sobre ingeniería o más   aplicando patrones estas de vuelta   donde empezaste.

     

Los patrones de diseño de software apelan a   programadores o desarrolladores porque   Permitir que se expresen naturalmente y   Crea bellas arquitecturas. Es un   parte de disfrutar de la programación creativa.

     

3. Considere refactorizar un patrón en lugar de comenzar desde uno

     

¿Cuál podría ser una buena manera de evitar esto?   diseño patrón de abuso? Considerar   refactorización a un patrón en lugar de   a partir de uno. No empieces   tratando de forzar un patrón en tu   diseño. Es probable que su diseño pueda   Ser mucho más simple sin él. Si lo haces   Encuentra en una etapa posterior que tu diseño.   Realmente podría beneficiarse de un estructurado   patrón, luego refactorizar para permitir   eso. Cuando diseñas, resuelve el problema.   De la forma más sencilla posible. Sencillo   software ligero es siempre una buena   cosa. Hay mejores maneras de   evitando la ingeniería insuficiente   alternativa donde te quedas atascado con una   diseño o solución que simplemente no es   lo suficientemente flexible o no se adapta a la   problema.

     

4. No te obligues a hacerlo bien la primera vez

     

Forzando patrones de diseño de software o   estructuras en el diseño simplemente no es el   respuesta, eso es simplemente mal diseño. Pero   Prototipando o construyendo una inicial.   build0 (prueba de concepto construir antes   producción en el producto real   comienza) puede ayudar a evitar esto y la   problema de sobre-ingeniería. Porque   no sientes que tienes que conseguirlo   perfectamente bien la primera vez.

  

cuándo dejar de hacer todo usando   patrones?

La pregunta es ¿cuándo empezaste a hacer todo utilizando patrones? No todas las soluciones encajan perfectamente en un patrón de diseño existente y la adopción de un patrón puede significar que enturbie la limpieza de su solución. Puede encontrar que en lugar de que el patrón de diseño resuelva su problema, genere otro problema al intentar forzar a su solución para que se ajuste a un patrón de diseño.

Obviamente, si elige el patrón de diseño correcto para un escenario particular, no tendrá ningún problema, sin embargo, elegir el correcto es más fácil decirlo que hacerlo.

He visto el uso excesivo de patrones en proyectos donde realmente no son necesarios.

Creo que la clave es : intente mantener su código limpio, modular y legible y asegúrese de que sus clases no sean estrechamente acoplado . Eventualmente puede ver que inadvertidamente ha utilizado una variación en un patrón de diseño estándar. Quizás se habría dado cuenta de esto al comienzo de su proyecto antes de comenzar a codificar. Si codificas como la mayoría de las personas que conozco (incluyéndome a mí), entonces probablemente no :)

Bueno, lo más importante es conocer el problema que estás resolviendo. De lo que necesita decidir si la introducción de algún patrón le otorgaría algunas ventajas sobre no usarlo (gane en rendimiento, simplicidad o lo que sea). Preguntas relacionadas: enlace

La regla es que no hay regla. Su experiencia (éxito más que fracasos) le dirá cuándo usarlos puramente, cuándo adaptarlos o cuándo no usarlos en absoluto.

Hay una presentación de Dan North en la que habla un poco sobre el aprendizaje y los patrones

El no. de los patrones de diseño mencionados en el texto original / de facto sobre el tema, es decir, GoF requiere un poco de experiencia y, a menudo, varias lecturas y una lluvia de ideas con colegas competentes para dominar. Publique esa etapa, dado un problema, dada una arquitectura, a menudo los patrones de diseño más naturales aparecen de manera bastante obvia. Sin embargo, cualquier intento de ajustar el patrón de diseño a los problemas, o mapear los problemas a los patrones de diseño está plagado de peligros, en cuyo caso es mejor consultar a expertos, hacer una tormenta de ideas y tomarlo como una experiencia de aprendizaje. A menos que se sienta cómodo con los 10 patrones de diseño más comunes, esto va a ser un poco complicado, y AFAIK, no hay atajos.

He llegado a través de millones de proyectos de código C ++ de SLOC con numerosos ejemplos de patrones de diseño de ajuste forzado, por lo que se cometen errores. el uso excesivo no es muy infrecuente.

En cierto modo, así sucede con cualquier tema que requiera que aprendas y apliques reglas :

1. Si eres un novato, debes seguir las reglas porque no te conoces mejor.
2. Si eres un aficionado, sigues los roles porque sabes por qué los necesitas.
3. Si eres un profesional, trabajas con las reglas en lugar de en contra de ellas, sabiendo bien qué usar cuando y dónde no se aplican.
4. Si eres un experto, ignoras las reglas.
5. Si ha dominado su arte, prefiere las reglas, ya que su código también debe ser visto por personas de categoría 1-3. :)

Es lo mismo con las artes marciales, pintura, escritura, fútbol, mecánica, carreras de carreras, etc, etc ...

Como un chico # 5, generalmente terminas enseñando a los chicos # 1- # 4 cómo convertirse en los mejores, por lo que siempre se aplica, incluso en contextos competitivos.

( Cómo trascender e ignorar las reglas explica esto en un sentido general, pero probablemente hay mejores ensayos por ahí.

Mantenga todo lo más simple posible. Sin embargo, si tiene que resolver un problema, es posible que desee utilizar un patrón de diseño, en lugar de reinventar la rueda, ya que muchos patrones de diseño proporcionan soluciones a problemas comunes. Pero como dije: solo úsalos cuando sea realmente necesario.

Tal vez use el patrón KISS DRY SoC (sí, quizás no sea un patrón, pero suena divertido).

Mantenlo simple, estúpido.
No te repitas.
Separación de preocupaciones.

Creo que estos tres puntos deberían ser inspiradores para cualquier programador.

El problema con los "patrones" es que cualquier cosa puede considerarse un patrón, y con frecuencia lo es.

Había estado desarrollando el código profesionalmente durante mucho tiempo antes de que escuchara a alguien hablar sobre "patrones", y me las arreglé bien durante todos esos años. De hecho, cuando miro hacia atrás, muchas de las cosas que escribí seguían algunos de los patrones bien conocidos, al menos hasta cierto punto.

Mi punto es que seguir rígidamente cualquier patrón dado no es realmente la respuesta. Aprende sobre nuevos patrones, pero no te ates a ellos: cambiarán. Una buena práctica de codificación hoy no es lo mismo que una buena práctica de codificación hace diez años, y no importa cuán inteligentes sean los programadores de hoy, puede estar seguro de que diez años en el futuro, las cosas que hoy se consideran una buena práctica se habrán superado.

Fuera del tema: en una nota personal, realmente odio el uso de la palabra 'patrones' en este contexto. Apesta a una jerga innecesaria.

Imho simplemente lo sabrás. Quiero decir que incluso utilicé un patrón de diseño antes de conocer la definición de patrón de diseño. Es solo una buena codificación. En algún momento podrá reconocerlo mientras escribe los requisitos del proyecto y en algún momento tendrá que refactorizar su código.

jwenting dijo KISS primero, patrones más tarde . Creo que los patrones son una forma de KISS de un proyecto porque puedes aplicar algo que sabes que funciona y te ahorrará tiempo en el futuro.

Lo único que podría salir mal es que hay muchas formas de implementar un solo patrón de diseño, incluso en el mismo idioma, por lo que debe entender completamente cuál es su problema .

La forma en que estructura la lógica de su código debería permitir que un recién llegado a ese código pueda interpretarlo y modificarlo. Tener un patrón solo porque es una buena práctica no lo llevará a ningún lado si no comprende completamente el contexto de cómo, quién y dónde se encuentra ese código y podría ser utilizado.

El patrón "Mantenlo simple" es más una cuestión de sentido común que un patrón y tiene que ser parte del proceso de pensamiento de un desarrollador al crear código. Asumir que todos obtienen un patrón particular no es necesariamente correcto también. Lo ideal es que desee un patrón que pueda leerse e identificarse sin tanto conocimiento de él.

Por lo general, los patrones de diseño se utilizan para explicar a la audiencia más amplia lo que realmente hace su código. De esta manera, hace que sea más fácil para las personas entender lo que estás haciendo. Rara vez se usa como referencia para encontrar soluciones, ya que un patrón puede implementarse de muchas maneras.