¿Son los patrones de diseño realmente esenciales hoy en día?

Por mi dinero, creo que a todos les falta el punto de los patrones de diseño. Es raro que me siente preguntándome 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 dominios grandes frente a los scripts de transacción si todos sabemos qué significan esos dos términos. Y así sucesivamente.

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

Incluso si no sabes de qué estoy hablando cuando digo "el patrón de observador es ideal para eso", podrás disparar y buscarlo en Google con bastante facilidad.

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

Los patrones de diseño son un aumento en el poder expresivo del lenguaje común que usamos como personas de software. Este lenguaje común no es esencial, pero hace que muchas soluciones comunes a los problemas sean más fáciles y rápidas de expresar. Por ejemplo, es mucho más fácil hablar de Singletons que de "clases en las que solo se supone que tenemos una instancia, pero que no se pueden convertir en estáticas y globales".

Las soluciones que brindan los patrones de diseño son útiles, pero son soluciones que probablemente ya haya pensado si enfrentó los problemas que resolvieron. Se requiere un cierto nivel de madurez para comprender los patrones de diseño: si nunca ha tenido que resolver el problema, no verá el valor o el interés en la solución.

Los patrones tienen dos propósitos principales:

• Resolver las tensiones de manera predecible : los patrones están diseñados para resolver un determinado 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 (y con frecuencia lo hacen), los patrones que las resuelvan seguirán siendo útiles.

• Multiplicador de fuerza de comunicación : los patrones nos permiten decir mucho con poco. Aprovechan un pequeño conjunto de conceptos poderosos y bien entendidos que son aplicables en una amplia variedad de espacios problemáticos. La respuesta de @ pdr está basada en 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, por lo que no necesita 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 idioma 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 empresarial.

Quizás el concepto de antipatrones sea 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 la prerrogativa del arquitecto de software en un proyecto, pero en realidad es algo que puede ser resuelto por consenso en el proverbial equipo "bien gelificado".

Pero los patrones de diseño y anti-patrones forman un recurso para esas discusiones. Uno debe 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 discusiones, pero realmente no es tan malo hacer referencia a los estándares de facto elaborados por los autores que han estado allí, ya lo he hecho.

Hay dos tipos de patrones de diseño:

1. Patrones universales , que son mucho más sobre cómo organizar programas complejos para que puedas entenderlos en absoluto. Estos no van a desaparecer, aunque se pueden descubrir más ejemplos de ellos.
2. Patrones de situación , 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.

Está bien, podría decirse que todos los patrones son de alguna manera situacionales, pero con algunos, las fuerzas provienen del mundo real y con otros, las fuerzas provienen 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 reinventarlas. Ninguna le impide realizar un gran progreso en un campo determinado una vez que tenga una comprensión sólida de lo que sucedió antes. ¿Crees que Rieman nunca leyó Euclides?

Hay beneficios en el diseño de patrones cuando reducen la cantidad de tiempo que sus colegas o clientes pasan pensando "¿Cómo funciona esto?". A pesar de que no tiene sentido imponer 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 suyos y trabajos. 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 el CLOS admite el envío múltiple, el mismo problema que el patrón de visitante está tratando de resolver.

Además, .NET Framework tiene un mecanismo de eventos integrado para la publicación de eventos en múltiples oyentes, lo que hace que el patrón Observer 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 las aplicaciones de una sola página, estos patrones pueden volver a ser relevantes en el lado del cliente.

Pero los patrones de diseño y los libros como "Patrones de diseño" o "Patrones de arquitectura de aplicaciones empresariales" son de gran valor cuando usted es un programador novato y se enfrenta a un nuevo tipo de problema por primera vez; Como era la primera vez que me pidieron que implementara la funcionalidad de Deshacer. Si no hubiera sido por el libro "Patrones de diseño", mi implementación probablemente hubiera 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 horriblemente 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 principiante, son valiosos, siempre y cuando recuerdes que son los medios para resolver un problema, y no una búsqueda para utilizar la mayor cantidad posible.

* la cita puede no ser 100% precisa ya que se toma de la memoria

** en mi experiencia, es muy común que las empresas elijan los mecanismos de entrega web para las aplicaciones internas de línea de negocio.

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

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