¿Deben los programadores seguir siempre los patrones de diseño? ¿Son los patrones de diseño las únicas formas eficientes de escribir mejores programas?

No. Hoy no hay una definición de qué es un patrón de diseño porque:

  • La mayoría de los patrones de diseño son conceptos intelectuales que no tienen sentido para usted cuando tiene experiencia, como Bridge, Flyweight, Composit, Mediator, Facad … todos estos son sentido común y resultado directo de OOP y no es necesario que sean reconocido como patrones de diseño
  • Algunos patrones de diseño son similares. El patrón de Comando es solo el patrón Adaptador (caso de uso diferente pero el mismo diseño), mientras que el Intérprete es el mismo para el Decorador. Parece que solo necesitaban un libro más grande en ese momento.
  • Están desactualizados. Hoy usarás recipientes de inyección de dependencia que harán la Fábrica y Singleton por ti, usarás Eventos / Delegados para el patrón de Observador.
  • No utilizan nuevas funciones de lenguajes de programación, como por ejemplo, las clases genéricas en C # y Java son patrones de diseño modernos que los patrones tradicionales que se le preguntarán en la entrevista no los reconocen. Otros ejemplos de características / diseños: Dinámica, Reflicción, Emisión de tiempo de ejecución …

Lo que debe hacer es el diseño correcto que cumpla con los tres principios de OOP, que son: Principio de responsabilidad única, Encapsulación y “No repetir”, sí, hay herencia y polimorfismo, simplemente olvide estos términos porque es mejor descubrirlos que tenerlos como principios El patrón de diseño surgirá de su caso de uso correctamente incluso para patrones estructurales como MVC y MVVM, es solo una cuestión de experiencia que obtendrá con el tiempo si cada vez que escribe un código piensa cómo podría mejorar el desacoplamiento y cómo cumplir Principios de OOP.

Los patrones de diseño son un poco como las aperturas de sonido en el ajedrez, y un poco como las recetas para cocinar alimentos.

Hacer movimientos de ajedrez al azar y mezclar ingredientes de cocina al azar a menudo conducen al mismo fin: indigestión y una sensación de fracaso.

Por el contrario, una buena apertura de ajedrez ha considerado las consecuencias de un movimiento dado, y qué se puede hacer mejor para mitigar esas consecuencias para lograr un buen resultado; Es un conjunto de movimientos bien conocidos que conducen a una posición sólida.

Del mismo modo, una receta de cocina ha tenido en cuenta las consecuencias químicas de las proporciones de los ingredientes, el tiempo y la temperatura para producir un resultado sabroso y no venenoso.

Un patrón de diseño es una forma de lograr algo. Se ha pensado detenidamente y se ha construido para mitigar las trampas comunes mientras se logra un buen resultado. Le ahorra tener que pensar detenidamente y mitigar todas las dificultades potenciales usted mismo.

No tiene que usar patrones de diseño. Es posible crear un código eficiente, funcional y confiable sin ellos. Sin embargo, a menudo es una pérdida de tiempo y esfuerzo intentarlo, cuando alguien más ya lo ha descubierto.

Acabo de dar un caso de uso del mundo real, cómo los patrones de diseño ayudan a resolver problemas.

¿Cuál es la diferencia entre framework y patrones de diseño en .net?

Cuándo no usar patrones de diseño

1 / Cuando hay restricciones de memoria.

2 / Las restricciones de rendimiento están ahí.

Usecase: cohete diseñado para enviar satélites … donde el tiempo y el espacio son más importantes y el código no mantenible …

Por último, responda a ‘¿Los patrones de diseño son la única forma de escribir programas?’: Sí y No … según la necesidad …

“Todo parece un clavo cuando tienes un martillo”

Los patrones de diseño son solo herramientas. Algunas veces usar un patrón de diseño es excesivo, otras veces es la solución perfecta. El truco es saber la diferencia.

Cada patrón de diseño trae consigo un cierto nivel de complejidad. Depende de usted como desarrollador evaluar si el valor de usar un patrón de diseño en particular vale la complejidad adicional que conlleva.

Los patrones de diseño nacieron para resolver problemas existentes. Si no tiene problemas en sus aplicaciones, o en ciertas partes de sus aplicaciones, no use patrones.

La forma correcta de aprender y usar patrones es:

  • Aprende el propósito de los patrones.
  • Aprenda cuándo y cómo usar patrones. Aprenda las modificaciones de patrones para casos individuales.
  • Lo más importante es : aprender cuándo NO usar patrones.

Hoy en día, las personas ya no aprenden en serio la informática y el diseño de aplicaciones, por lo que aprenden patrones de la forma en que los monos ven y usan los monos.

Es el abuso de los patrones de diseño. Pero las personas que le dicen que no use Patrones de diseño en TODOS los casos son puramente estúpidas.