¿Los patrones de diseño son realmente esenciales hoy en día?

107

Estaba leyendo "Codificadores en el trabajo" y me he enfrentado al hecho de que algunos de los profesionales entrevistados en el libro no están tan entusiasmados con los patrones de diseño.

Creo que hay 2 razones principales para esto:

  1. Los patrones de diseño nos obligan a pensar en sus términos. En otras palabras, es casi imposible inventar algo nuevo (tal vez mejor).

  2. Los patrones de diseño no duran para siempre. Los idiomas y las tecnologías cambian rápidamente; por lo tanto, los patrones de diseño eventualmente se volverán irrelevantes.

Entonces, tal vez sea más importante aprender a programar correctamente sin patrones particulares y no aprenderlos.

El punto también era que, por lo general, cuando las personas enfrentan un problema y no tienen mucho tiempo, intentan usar un patrón. Esto significa copiar y pegar el código existente en su proyecto con pequeños cambios para que funcione. Cuando es hora de cambiar o agregar algo, un desarrollador no sabe por dónde comenzar porque no es su código y no está muy familiarizado con él.

Sergey
fuente
79
Si aplicar un patrón significa copiar y pegar el código existente, entonces probablemente lo esté haciendo mal
Dyppl
99
usando patrones de diseño! = programación de culto de carga
jhocking
11
El título de esta pregunta puede reformularse como "¿No es realmente necesario reinventar la rueda hoy en día?"
Eric King
2
Los patrones de diseño nos obligan a pensar en sus términos , si los dejas. El conocimiento de los patrones me permite considerar las posibilidades para un problema de diseño dado. A menudo es como leer el menú de un restaurante ... "no, no, interesante, no, hmm, a-ha!". Además, las características del lenguaje moderno a menudo hacen que los diagramas de patrones específicos, codificados hace décadas, sean arcaicos.
radarbob

Respuestas:

261

Por mi dinero, creo que a todos les falta el punto de los patrones de diseño. Es raro que me pregunte qué patrón debo usar en una situación dada. Además, estaba usando la mayoría de esos patrones mucho antes de saber que tenían nombres.

El poder de los patrones de diseño está en la comunicación. Es mucho más rápido para mí decir "usar una estrategia para eso" que describir en detalle lo que estoy sugiriendo. Es mucho más fácil para nosotros debatir los beneficios de los modelos de dominio gordo frente a los scripts de transacción si todos sabemos lo que significan esos dos términos. Y así.

Y lo más poderoso de todo, si he nombrado una clase FooBuilder, entonces sabes que estoy usando el patrón Builder para generar mi Foo.

Incluso si no sabes de lo que estoy hablando cuando digo "El patrón de observador es ideal para eso", podrás salir y buscarlo en Google con bastante facilidad.

En ese sentido, el poder de los patrones de diseño nunca se desvanecerá.

pdr
fuente
55
+1 para "Estaba usando la mayoría de esos patrones mucho antes de saber que tenían nombres". Todos han existido durante mucho tiempo, solo que sin la nomenclatura de patrones. En 1991, estaba escribiendo singletons en C, y le mostré uno a un programador más experimentado que nunca lo había visto antes y pensó que era bastante ingenioso.
Bob Murphy
8
Sin embargo, los patrones también desaparecen. En la década de 1950, la "llamada de subrutina" era un patrón bastante popular. En C, "objeto" es un patrón (algo) popular. Ambos están prácticamente extintos, ya que fueron absorbidos en los lenguajes modernos y (en el caso de las subrutinas) incluso en los conjuntos de instrucciones de las CPU modernas.
Jörg W Mittag el
99
@Bob Murphy: Argh Singleton :( :( @pdr: exactamente, los patrones son sobre comunicación sobre programación. Aplicar un patrón porque casi encaja es el error más grande que uno puede cometer, y por lo tanto, la reflexión del diseño no debe hacerse en términos de patrones, solo deberían ingresar al diseño cuando se trata de explicar lo que pensabas: "Es casi como un <patrón> excepto que lo he ajustado ..." Creo que el propio GOF lo reconoce: los patrones se recortan / simplifican visiones, necesitan ser adaptados a la situación particular.
Matthieu M.
10
@Jorg: cuándo desapareció el patrón de "llamada de subrutina". ¿Qué crees que es una llamada a método / función?
Dunk
10
@Dunk: Depende de los idiomas que esté utilizando, por supuesto. No sé qué idiomas se está utilizando, pero en todos los idiomas que estoy usando hoy en día, llamadas a subrutinas son una característica incorporada en el lenguaje, no un patrón de diseño. Sin embargo, en C, por ejemplo, la llamada al método es un patrón de diseño, mientras que en Java es una función de lenguaje incorporada.
Jörg W Mittag
15

Los patrones tienen dos propósitos principales:

  • Resolver tensiones de manera predecible : los patrones están diseñados para resolver un cierto conjunto de tensiones de una manera que se sabe que funciona. Kent Beck, autor de Smalltalk Best Practice Patterns , describe los patrones como una forma de repetir la decisión que tomaría un experto en circunstancias similares. Mientras las tensiones sigan siendo las mismas (ya menudo lo hacen), los patrones que las resuelvan seguirán siendo útiles.

  • Multiplicador de la fuerza de comunicación : los patrones nos permiten decir mucho con poco. Aprovechan un pequeño conjunto de conceptos potentes y bien entendidos que son aplicables en una amplia variedad de espacios problemáticos. La respuesta de @ pdr es acertada sobre el valor comunicativo de los patrones.

Rein Henrichs
fuente
12

Creo que la afirmación de que los patrones de diseño obstaculizan la innovación es completamente falsa. Debe saber dónde ya existe para no tener que reinventar la rueda. Por ser temporales, los patrones en su conjunto se aplican a los sistemas OOP y no están vinculados a ninguna plataforma o lenguaje en particular.

Ahora, lo que no me gusta cuando la gente habla de patrones es que algunas personas tienen una especie de obsesión con ellos. Una vez tuve un cliente que me pidió "que incluyera al menos dos patrones más" (¡¿WTF ?!) ya que debido a la falta de palabras de moda en mi código no parecía lo suficientemente emprendedor.

Vitor Py
fuente
3
Mi experiencia es que el código bien escrito se ajusta a múltiples patrones de diseño precisamente porque describen buenas prácticas. Por lo tanto, para satisfacer a su cliente, debería haber sido solo una cuestión de detectar cuáles ya estaba usando y poner sus nombres en los documentos. ¡Fácil!
Donal Fellows
1
@Donal Fellows Eso es lo que hice :) Terminé encontrando patrones de manchas y nombrándolos, dando al proyecto un final feliz. Mi mayor problema es que fue un proyecto muy, muy pequeño (aproximadamente una semana de trabajo) y muy sencillo: leía datos de un formato de datos extraño, hacía un par de transformaciones, graficaba los datos y los hundía en una base de datos.
Vitor Py
@Vitor Estoy totalmente de acuerdo contigo. ¡Personalmente conozco personas que piensan que buscar un patrón de diseño que se adapte a su problema / escenario es una mala idea! Prefieren reinventar la rueda. ¡Temo que algún día puedan despertarse y pedirme que no use las clases Java IO y que escriba mis propios controladores IO!
CKing
6

Quizás el concepto de antipatrones es pertinente. No pienso en estudiar patrones de diseño como el paso crítico para convertirse en ingeniero de software. El diseño de software es importante, a menudo reservado como prerrogativa del arquitecto de software en un proyecto, pero de manera realista es algo que se puede resolver por consenso en el proverbial equipo "bien gelificado".

Pero los patrones de diseño y los antipatrones forman un recurso para esas discusiones. Hay que apreciar las lecciones de cosas que funcionaron bien (o no) y cómo capitalizar (o mitigar) las consecuencias de las elecciones de diseño. Un buen equipo podría crear su propio vocabulario para tales debates, pero en realidad no es tan malo hacer referencia a los estándares de facto elaborados por los autores que han estado allí, hecho eso.

hardmath
fuente
3
"Anti-patrón" es solo un eufemismo de largo aliento para "malo".
Michael Shaw
@hardmath "Anti-pattern" significa mucho más que simplemente 'malo'
GoatInTheMachine
1
@GoatInTheMachine: Estoy de acuerdo, ese fue un comentario en mi publicación. Si bien los antipatrones son ejemplos de qué evitar, tienen rasgos característicos que los hacen opciones de diseño atractivas. A veces es razonable seguir conscientemente un antipatrón, sabiendo sus defectos y trampas.
hardmath
4

Hay dos tipos de patrones de diseño:

  1. Patrones universales , que tratan mucho más sobre cómo organizar programas complejos para que pueda comprenderlos. Estos no desaparecerán, aunque se pueden descubrir más ejemplos de ellos.
  2. Patrones situacionales , que están tan ligados a las fuerzas particulares inducidas por las restricciones (por ejemplo, el lenguaje de programación) que cuando esas fuerzas cambian, se vuelven irrelevantes.

Bien, podría decirse que todos los patrones son algo situacionales, pero con algunos las fuerzas son del mundo real y con otros las fuerzas son de las herramientas. Las herramientas cambian mucho más rápido que el mundo real.

Compañeros de Donal
fuente
Todos los patrones se definen por la forma en que resuelven un cierto conjunto de tensiones. Mientras las tensiones sean las mismas (y con frecuencia lo son, por eso son patrones ), los patrones seguirán siendo útiles.
Rein Henrichs
@Rein: Pero las fuerzas que crean las tensiones pueden ser internas o externas. Diferentes lenguajes tienen diferentes fuerzas internas (por ejemplo, los patrones relacionados con las interfaces son más relevantes para Java que para C ++ debido a las diferentes tensiones en sus sistemas de clases).
Donal Fellows
Seguro. Una mirada a través de los Patrones de implementación (libro de patrones Java de Kent Beck) muestra una distribución bastante uniforme entre los patrones de propósito general y los que son más específicos de las características de Java. Comparar ese libro con los patrones de mejores prácticas de Smalltalk también es revelador.
Rein Henrichs
3

Leer sobre patrones de diseño es como aprender matemáticas en lugar de reinventarlos. Ninguno le impide hacer un gran progreso en un determinado campo una vez que tenga una sólida comprensión de lo que sucedió antes. ¿Crees que Rieman nunca leyó Euclides?

Gus
fuente
1

Los patrones de diseño son beneficiosos cuando reducen la cantidad de tiempo que sus colegas o clientes pasan pensando "¿Cómo funciona esto?". Aunque no tiene sentido aplicar un estándar por el bien de la estandarización, si hay una forma común y bien entendida de hacer algo, cada vez que un codificador busca ese patrón esperando encontrarlo y lo hace, usted ha hecho su trabajo y el suyo. más fácil.

Tom W
fuente
1

Creo que la pandilla de cuatro clasifica los patrones de diseño como

Una solución común a un problema común *

Entonces sí, los patrones son relevantes cuando ocurre el mismo tipo de problema. Y esto nos lleva a un problema con el término "Patrón de diseño". Un patrón es algo reconocible que ocurre repetidamente. Entonces, en realidad no hay un patrón de diseños, hay un patrón de problemas.

Algunos lenguajes de programación pueden tener soluciones nativas para algunos de esos problemas. El libro "Patrones de diseño" en sí mismo menciona que el patrón de visitante tiene poco valor si está utilizando CLOS, ya que CLOS admite de forma nativa el envío múltiple, el problema que el patrón de visitante está tratando de resolver.

Además, el marco .NET tiene un mecanismo de eventos incorporado para publicar eventos a múltiples oyentes, lo que hace que el patrón de Observador sea menos relevante en este contexto.

El cambio de aplicaciones de escritorio a aplicaciones web ** también cambia el tipo de problemas de programación que tenemos que resolver. Muchos de los patrones en el libro "Patrones de diseño" son relevantes para aplicaciones de escritorio, pero no tanto para aplicaciones web. Por supuesto, con aplicaciones de una sola página, estos patrones pueden ser relevantes nuevamente en el lado del cliente.

Pero los patrones de diseño y libros como "Patrones de diseño" o "Patrones de arquitectura de aplicaciones empresariales" son de gran valor cuando eres un programador novato y te enfrentas a un nuevo tipo de problema por primera vez; Como era la primera vez que me pidieron que implementara la funcionalidad Deshacer. Si no hubiera sido por el libro "Patrones de diseño", mi implementación probablemente habría sido algo así como almacenar una instantánea de los datos después de cada operación de cambio de estado ***, un enfoque muy propenso a errores y terriblemente ineficiente.

Entonces, sí, algunos de los patrones se vuelven menos relevantes con el tiempo, y a medida que te conviertes en un programador experimentado, piensas menos en ellos. Pero para un novato, son valiosos, siempre y cuando recuerde que son los medios para resolver un problema, y ​​no una búsqueda para usar la mayor cantidad posible.

* la cotización puede no ser 100% precisa ya que se toma de la memoria

** en mi experiencia, se está volviendo muy común que las empresas elijan mecanismos de entrega web para aplicaciones de línea de negocios internas.

*** después de aprender programación funcional y estructuras de datos funcionales, entonces esa podría ser la forma en que lo resolvería hoy.

Pete
fuente
-3

La adhesión servil a los patrones de diseño puede ser perjudicial: los patrones son soluciones documentadas a problemas comunes, pero no son manuales de instrucciones. Sin embargo, solo porque se discutan extensamente y, en algunos casos, se apliquen fuera de dominios de problemas efectivos no significa que no tengan ningún valor. Son un conjunto de principios, llámelo marco, a los que recurrir cuando se diseña la arquitectura de un programa, lo que permite al arquitecto dar una impresión de cómo le gustaría que funcionara la solución. Un buen equipo de desarrollo los ve como una base para la funcionalidad, en lugar de una especificación funcional.

Jacob Harrington
fuente
2
esto no parece ofrecer algo más de substantisl puntos realizados y explicados en anteriores respuestas
mosquito