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

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.

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á.

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.

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.

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.

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.

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?

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.

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.

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.