Así que es un poco extraño hacer dos preguntas seguidas, pero no están muy relacionadas y no quería combinarlas, pero no estoy enviando preguntas de spam, ¡lo prometo!

De todos modos, soy un recién graduado de la universidad, y mi educación solo tocó patrones de diseño ... implementamos algunos simples, tocamos el hecho de que había otros más complicados y se nos instruyó que pasaran al libro de GoF si Quería aprender más. Mi pregunta es, ¿vale la pena aprender los patrones en el libro GoF? Para mí, siempre me pareció contrario a la intuición intentar hacer que un problema se ajuste a un patrón clásico, pero obviamente el libro y los patrones son famosos por una razón. ¿Aparecen lo suficiente como para que yo los esté aprendiendo?

¡Gracias de nuevo!

Como siempre

Depende

Depende de la cantidad de POO que haya hecho en cuanto a si reconocerá o incluso podrá utilizar los patrones de diseño

Depende de lo disciplinado que seas en cuanto a si aplicarás los patrones una vez que aprendas correctamente, y no volverse loco como el hombre proverbial con un martillo

Por otro lado ... ¡cinco dedos!

Si has realizado un par de años de trabajo serio en OOP o tienes un mentor confiable para mantenerte en los rieles o simplemente te gusta la lectura de NOP-nerd, entonces ve a comprar el libro y estudiarlo.

Es útil conocer los patrones para que pueda reconocer cuándo usarlos y cuándo no usarlos.

Sí, deberías aprenderlos.

Tiene aún más sentido volver a visitarlos después de haber adquirido cierta experiencia , para que pueda compararlos con lo que sabe. Para algunos patrones resultará que esto es algo que ha descubierto usted mismo, pero aprenderá algo más general sobre su uso, compensaciones, variantes, etc. Puede parecer que otros abordan directamente los problemas que enfrentaste y te muestran una solución elegante que no conocías.

La gran mayoría de los patrones es muy útil y común . Otros pueden no ser tan populares, pero aún tienen un uso limitado donde se ajustan perfectamente.

Hay una razón más por la que vale la pena leerlo: te enseñará a pensar . Claro, no es una bala de plata, pero sigue siendo una inspiración invaluable.

Por último, pero no menos importante, nunca, nunca, bajo ninguna circunstancia intente hacer que un problema se ajuste a un patrón o herramienta . ¡Eso es un pensamiento muy malo y peligroso! Comprenda cómo funciona la herramienta y úsela sabiamente para tratar el problema, nunca al revés.

Cuantas más herramientas conozca bien, mejor. A veces, una herramienta puede inspirar su pensamiento (en lugar de resolver un problema directamente), en otra ocasión combinará algunos de ellos para una gran solución.

El libro GOF es una gran fuente de muchas herramientas útiles que usamos a diario .

El beneficio más importante de conocer un poco sobre Design Patters es que sabes lo que significan los términos. En otras palabras, conoces el vocabulario común .

Este es, para mí, el logro más importante de toda la confusión de los patrones de diseño, que ha surgido un vocabulario común en el que puedes usar los nombres de los patrones específicos, y otros saben de inmediato de lo que estás hablando sin tener que explicarlo. . Las cosas que describen los patrones son bien conocidas por la mayoría de los programadores, pero lleva tiempo explicar lo que significan para los demás, por lo que facilita la comunicación para conocer los nombres de los patrones.

Ejemplos son Visitor, Singleton y Decorators.

En otras palabras, le sugiero que al menos se familiarice con los nombres y lo que hacen.

SÍ pero con cautela!

La parte SÍ:

A veces, encontramos problemas en nuestros diseños. A veces, esos problemas son muy comunes, por lo que los patrones de diseño le brindan soluciones bien probadas para esos problemas. Los principales beneficios de aprender patrones de diseño es que puede encontrar una solución de diseño mucho más rápido y si sus compañeros de trabajo conocen la jerga del patrón de diseño , también puede explicar una solución mucho más rápido.

La parte cautelosa:

Los patrones de diseño no deberían ser el santo grial de sus soluciones. La solución más simple (KISS) es más deseada y muchas veces los patrones de diseño harán las cosas más complejas. Si está aprendiendo patrones de diseño, también aprenda sobre antipatrones. Conozco a algunas personas mayores que están en contra de los patrones de diseño y estoy de acuerdo en cierta medida con ellos porque cuando no tienes demasiada experiencia en codificación pero tienes mucha teoría del patrón de diseño, podrías terminar haciendo las cosas mucho más difíciles para ti y tu equipo.

Por último, no piense que tiene que ajustar / cambiar su solución solo para cumplir con un patrón de diseño. Por el contrario, puede doblar un patrón de diseño para que se ajuste a su solución. Está bien si no está usando todos los ingredientes de una receta de patrón de diseño siempre que tenga una mejor solución para su problema particular. Piense en los patrones de diseño como una sugerencia y no como la regla para su solución.

He encontrado el método de Net Objectives de pensar en los patrones como el más beneficioso. Las personas que leen el libro GoF con demasiada frecuencia comienzan a asumir que las estructuras que muestran, en notación de diseño y en código, son los patrones y que así es siempre como se ven. Hay una manera diferente y posiblemente mejor de verlo.

Los patrones son conjuntos de problemas similares que pueden resolverse con ciertas fórmulas abstractas, no con conjuntos de fórmulas que pueden usarse para resolver varios problemas. Lo que esto significa es que el patrón ya está allí antes de que incluso comience a intentar hacer un diseño, el objetivo del diseñador es encontrarlo , no imponerlo.

Además, mucha gente mira los patrones y dice: "Oh, lo resolví ... no utilicé ningún patrón tonto". La cuestión es que "..." describe casi inevitablemente una implementación AN de una solución de patrón dada. Por ejemplo, una serie de punteros de función podría servir como una Cadena de Responsabilidad, aunque esta no sea la receta tradicional.

Con esto en mente, el enfoque en su estudio de los patrones debe estar en los problemas, no en los patrones. Aprenda los factores motivadores de los patrones y cómo abordan esos factores. Hacer esto le permitirá ver los patrones en el problema y luego simplemente señalarlos. Esto, junto con el lenguaje que nos dan los patrones para hablar sobre diseño, le permite exponer un diseño muy adecuado para responder a las diversas dificultades que enfrenta actualmente.

SÍ, en resumen, los patrones de aprendizaje no solo valen la pena ... te limitas al NO aprenderlos. No quiero tener que describir todos los principios motivadores y la forma general de solución cuando digo: "Me parece un visitante".

Aquí está su sitio web: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

Los patrones de diseño descritos por GoF son una especie de extensión natural del paradigma OO. Si no comprende completamente los objetivos de OOP (encapsulación, separación de preocupaciones, el principio DRY, modularidad, etc.), entonces intentar aplicar patrones de diseño con éxito no tiene mucho sentido.

Sin embargo, si te mojas los pies en la OOP del mundo real y tratas de ser fiel a los valores de la OOP, inevitablemente entrarás en situaciones como las descritas por el GoF, y es probable que inventes soluciones similares a las de ellos. Después de resolver muchos problemas similares, puede comenzar a ver surgir patrones; en este punto, tiene sentido leer el libro; idealmente, tendrá una sensación de reconocimiento e inmediatamente apreciará la elegancia y la limpieza de los patrones propuestos. Lo más probable es que también consideres algunos de estos patrones sin cerebro (que, una vez que los conoces, muchos de ellos lo son). También podrá juzgar bien si un determinado patrón es aplicable o no en una situación dada.

Y aquí hay otra advertencia: el hecho de que conozca todos estos patrones no significa que tenga que aplicarlos en todas partes. Algunos de ellos son bastante inteligentes, y la gente se siente tentada a usarlos incluso cuando son horriblemente inapropiados, siendo el patrón Singleton el ejemplo más famoso (gran parte de la controversia de Singleton proviene del uso inapropiado, por ejemplo, cuando no hay beneficio en tener uno -restricción de solo instancia).

Los patrones de diseño intentan resolver problemas de diseño.

• Se hicieron AFAIK principalmente para los idiomas OOP.
• Algunos de los problemas no existen en la programación funcional (el patrón de comando es cómo hacer funciones de primera clase, el patrón de estrategia se aproxima a la función de orden superior ...). Estos patrones son para lenguajes (principalmente OOP) que no tienen la funcionalidad necesaria.
• Están ordenados alfabéticamente. Varios patrones son composición de otros o las ideas se componen de las que estaban allí antes.

Más tarde aprendí patrones, después de conocer algunos programas funcionales, UML, diseño de bases de datos, estructuras de datos y algoritmos. De hecho, solo revisé la lista de diseños de estos patrones en la hoja de trucos y asentí con la cabeza porque ya conozco la mayoría de ellos. Algunos eran realmente agradables como los patrones singleton o de "comunicación" (visitante, mediador) ...

Estoy de acuerdo con los puntos formulados en otras respuestas sobre cómo puede ser peligroso aplicar patrones de diseño con poca experiencia.

Aún así, recomiendo leer al menos el primer capítulo del libro GoF. La primera sección le presentará los patrones de diseño, pero en realidad trata más sobre los principios del diseño OO, y esto debería ser beneficioso para leer y comprender incluso con relativamente poca experiencia. (Algunas ideas clave que recuerdo incluyen "encapsular los conceptos que varían", "las jerarquías de herencia deben ser amplias pero no profundas"). Es casi una pena que el trabajo sea conocido principalmente por sus 23 patrones: su discusión sobre los principios de diseño de OO que informó esos patrones también es extremadamente valioso.

Mi pregunta es, ¿vale la pena aprender los patrones en el libro GoF?

¡Absolutamente! Debe aprender no solo los patrones de diseño de software, sino también las técnicas de diseño en general. Aprender soluciones comunes a problemas comunes es un comienzo fantástico. Especialmente una vez que comienzas a profundizar en los patrones y sus compensaciones.

¿Aparecen lo suficiente como para que yo los esté aprendiendo?

El libro original Gang of Four fue desarrollado al examinar muchos proyectos de software y ver técnicas que varios desarrolladores han utilizado para resolver problemas. Los autores notaron algunas técnicas realmente buenas, así como un número que se aplicó en proyectos muy disjuntos y trabajó para abstraerlos aún más para que sean útiles independientemente del dominio.

siempre parece contra-intuitivo intentar hacer que un problema se ajuste a un patrón clásico

Este es un gran problema. No haces que un problema se ajuste a la solución. En cambio, el libro de patrones de diseño Gang of Four tiene una sección de "problema" para cada patrón, y otros catálogos de patrones tienen secciones similares, que describen cuándo debe aplicar cada patrón. También describe las "consecuencias" de usar el patrón: si está tratando de evitar una consecuencia, entonces usar el patrón no es la mejor idea.