Cuando era un programador novato, me encantaban los patrones de diseño. No solo usé patrones de diseño. Yo los infligí. Donde quiera y cuando pueda. Fui despiadado. Jajaja Patrón observador! ¡Toma eso! ¡Usa un oyente! ¡Apoderado! AbstractFactory! ¿Por qué usar una capa de abstracción cuando cinco hará? He hablado con muchos programadores experimentados y descubrí que casi todos los que leen el GoF Book pasan por esta etapa.

Los programadores novatos no usan patrones de diseño. Abusan de los patrones de diseño.

Más recientemente, me parece que tener en cuenta principios como el Principio de Responsabilidad Única y escribir pruebas en primer lugar, ayuda a que los patrones emerjan de una manera más pragmática. Cuando reconozco los patrones, puedo continuar progresándolos más fácilmente. Los reconozco, pero ya no intento forzarlos en el código. Si surge un patrón de Visitante es probablemente porque he refactorizado la duplicación, no porque pensé con anticipación en las similitudes de renderizar un árbol en lugar de sumar sus valores.

Los programadores experimentados no usan patrones de diseño. Los patrones de diseño los utilizan.

Ya sea que uno los reconozca o no, la mayoría de los programadores hacen usan patrones.

Sin embargo, en el trabajo del día a día, uno no comienza a programar con un patrón en mente, uno reconoce que un patrón ha surgido en el código y luego lo nombra.

Algunos de los patrones comunes están integrados en algunos lenguajes, por ejemplo, el patrón de iterador integrado en C # con el foreach keyword.

Algunas veces ya conoce el patrón que utilizará como una solución común al problema en cuestión (diga el patrón de repositorio - ya sabes que quieres representar tus datos como una colección en memoria).

Como está implícito en la respuesta pdr vinculada: los patrones de diseño son nombres dados a las cosas que las personas estaban haciendo de todos modos , con la intención de facilitar que las personas discutan esas cosas.

En general, vale la pena aprenderlos al comenzar, porque le brindan información sobre las soluciones que las personas han encontrado para trabajar, para que pueda aprovechar los años de experiencia, y trial & error.

La discusión de los problemas motivadores incluidos con los patrones puede ofrecerle una idea de las buenas maneras de atacar su problema en primer lugar, pero a menos que su conocimiento de patrones le permita reconocer que existe una solución existente bien conocida, aún debe concentrarse en simplemente resolviendo el problema primero.

Si resulta que usar uno o más patrones existentes es excelente, tienes nombres listos para usar que facilitarán que otros entiendan tu código.

En términos generales, no. Hay momentos en que surgen patrones de mi código, pero en general, no los busco y ciertamente no digo "¡Oh, el Patrón de Puente resolvería mi problema!".

Aquí está la cosa. La mayoría de los patrones son objeto de abuso y mal uso sin que las personas consideren si son un buen diseño. Los patrones no son átomos. El código no se compone de X permutación de patrones. Sin mencionar que no todos los patrones son realmente buenas ideas, o que algunos idiomas tienen soluciones a nivel de lenguaje que son muy superiores a algunos patrones.

sí, la mayoría de los programadores que he encontrado utilizan el patrón más común que existe, la Big Ball of Mud . Por lo general, comienzan con arquitecturas bien diseñadas, pero por lo general terminan aquí, especialmente si comienzan a pensar que "debemos usar patrones de diseño" en todo el lugar y refactorizamos sin piedad.

  

los usas?

Sí, los programadores experimentados definitivamente lo hacen. Puedes evitar usar la mayoría de los patrones de diseño (excluyendo cosas singleton simples) por ahora; pero cuanto más programes y más complejos sean los sistemas que construyas, más sentirás la necesidad de usar patrones de diseño. Si aún lo evita, comenzará a sentir el dolor cuando tenga que expandir su sistema y cambiarlo según los nuevos requisitos.

  

Si en algún lugar de la web encuentro una manera de resolver mi problema, ¿es esto un   patrón de diseño?

No necesariamente. Un patrón de diseño se refiere a una forma específica de diseñar clases, sus comportamientos e interacciones para lograr un objetivo específico (o evitar un problema específico). Es posible que lo que haya encontrado no sea realmente un problema de diseño, sino una secuencia específica de pasos para programar una determinada API. Por ejemplo: hay una cierta secuencia para establecer una conexión de socket. Hazlo mal y tu zócalo no se comunicará. Esa secuencia de pasos no constituye un patrón.

  

¿Ustedes (programadores) se encuentran buscando patrones?

Sí. Los patrones de diseño encarnan el axioma "más vale prevenir que curar". Si puede detectar un problema particular de diseño próximo de antemano, puede evitar rediseños masivos para adaptarse a los cambios más adelante. Por lo tanto, vale la pena conocer los patrones de diseño de antemano y buscar lugares donde necesite usarlos a medida que construye su aplicación.

  

¿dónde se supone que debo mirar por cierto?

Como estudiante, probablemente no haya visto los problemas típicos que inspiran los patrones de diseño. Recomiendo encarecidamente que consulte Head First Design Patterns . Primero presentan un problema de diseño y luego muestran cómo un patrón en particular puede resolverlo / evitarlo.

Los patrones de diseño no se enseñaban cuando estaba en la escuela. Y, durante la mayor parte de mi carrera de programación, he trabajado con código heredado, no orientado a objetos. En los últimos años, he tratado de aprenderlos porque suenan como una buena idea. Sin embargo, debo confesar que cada vez que he cogido un libro o intentado leer un tutorial sobre el tema, mis ojos se han vuelto vidriosos y realmente no he aprendido nada práctico sobre ellos.

No puedo creer que lo haya admitido en público. Creo que probablemente acabo de perder cualquier credito geek que pueda haber establecido a lo largo de los años.

No busques tendencias

Cualquier solución de programación estándar para un determinado problema puede considerarse un patrón de diseño, sin importar qué tan populares sean, o si otros programadores las usan o no.

Es posible que ya esté utilizando un patrón de diseño que aún no se ha inventado / especificado.

No intentes usarlos, intenta pensar en sus términos

El problema con los patrones de diseño es que a veces los programadores quieren encajar sus problemas cuando es al revés.

Recuerde que la convención de diseño de patrones de diseño tiene un problema típico que resolver, incluso puede combinar patrones de diseño para abordar otros problemas más grandes. Esto es algo típico en las Arquitecturas Orientadas a Servicios, solo vea algunos de los patrones SOA que existen .

Búscalos en la naturaleza

Hay muchos proyectos de código abierto en los que encontrarás patrones de diseño aplicados. Un ejemplo que me viene a la mente es Joomla: encontrarás singletons , observadores . Las bibliotecas GUI tendrán el patrón de decoración , patrón de comando implementado, y tal vez incluso flyweight .

Hay otros patrones como los patrones de datos, por ejemplo, el Proyecto Doctrine solo ha usado, el patrón de registro activo ( 1.x), patrón del administrador de entidades (2.x), unidad de trabajo , repositorio , objeto de consulta , asignación de metadatos , mapeo de datos , y otros más generales como patrón de estrategia , y patrón decorador .

Hay tantas soluciones interesantes para elegir. Consulte Patrones de arquitectura empresarial de Martin Fowler , también hay patrones de modelo de datos .

Solo aprende para cuando llegue el momento

Apréndalos, conózcalos, obsesione con ellos y cuando llegue el momento sabrá cómo resolver el problema de programación x, ya será un mejor programador para ese momento.

Conviértete en un arquitecto

Yo diría que ser capaz de pensar en términos de patrones para resolver problemas, de manera efectiva te convierte en un arquitecto de software . Incluso si no quiere ser un arquitecto de software per se, sus soluciones tendrán más calidad técnica, serán más limpios y tendrán una mejor escalabilidad, en términos de diseño, de forma predeterminada.

Programé durante aproximadamente 7 años en C ++ y aprendí patrones hace aproximadamente 2 años. La mayoría de los patrones probablemente tienen algunas aplicaciones, pero en mi uso, algunas son mejores que otras. Tienes que pensar por qué los estás utilizando.

El patrón del iterador ha hecho que mi código sea más confuso y ha agregado una complejidad innecesaria. Puedo obtener la misma capacidad de mantenimiento utilizando typedefs para tipos de vectores STL. Y cualquier cambio que haga en la clase que se está iterando también debo hacer en la clase de iterador.

El método de fábrica, sin embargo, ha sido extremadamente útil, basado en el polimorfismo que proporciona. Olvido quién lo dijo, pero la afirmación "reusabilidad significa que el código antiguo puede usar un código nuevo", es definitivamente cierto con el patrón de fábrica.

He usado el patrón de método de plantilla durante años sin siquiera saber que era un "patrón de diseño".

El patrón Observer ha sido útil en algunos casos, a veces no. A veces hay que predecir la complejidad para determinar si la complejidad de la sobrecarga del patrón Observer vale la pena. Tenemos un programa que usa alrededor de 10 suscriptores y podría haber muchos más, por lo que el patrón de observador / suscriptor ha sido útil. Otro programa, sin embargo, tiene dos pantallas GUI. Implementé el patrón de observador para este programa, y ha sido en gran medida innecesario, simplemente porque agregó complejidad y no anticipo agregar más pantallas.

Creo que aquellos que dicen usar patrones siempre asumen que su programa va a ser infinitamente complejo, pero al igual que con todo, hay un punto de equilibrio en términos de complejidad.

Agregando a Lunivore. Me gustaría citar esto del primer libro de la cabeza

        ## **Three steps to great software** ##     

• Asegúrese de que el software haga lo que el cliente quiere
• Aplicar buenos principios orientados a objetos
• Luche por un diseño reutilizable y mantenible

Es durante la tercera etapa, después de que su sistema esté funcionando como se supone que debe hacerlo. Es hora de aplicar los patrones para preparar su software durante los próximos años.

  

¿Son realmente utilizados por la mayoría de los programadores?

Supongo que sí. En ADO.Net hay una clase de DataAdapter para dar un ejemplo simple, aunque dependiendo de qué área desea especializar, los patrones pueden variar.

  

Hablando de experiencia, he tenido algunos problemas durante la programación,   Cosas que no pude resolver por un tiempo, pero google y algunas horas de   La investigación resolvió mi problema. Si en algún lugar de la web encuentro una manera de   resuelve mi problema, ¿es este un patrón de diseño? ¿Lo estoy usando?

No, eso no es un patrón de diseño para mi mente. Un patrón de diseño tiende a tener una disposición de clases y métodos que definen la receta de un patrón.

Prefiero pensar en lo que hiciste allí como una práctica común. Sin embargo, tenga cuidado con la codificación de copiar y pegar.

  

Y también, ¿ustedes (programadores) se encuentran buscando patrones   (¿dónde se supone que debo mirar por cierto?) cuando comienzas el desarrollo? Si   Por lo tanto, este es ciertamente un hábito que debo comenzar a adoptar.

Algunas veces, cuando veo el mismo código una y otra vez, puedo encontrar una manera de refactorizar el código en un patrón o si recuerdo una solución a un problema similar que involucra un patrón, lo sacaré y lo usaré. Head First Design Patterns tiene más de unos pocos patrones mientras que Refactoring sería una sugerencia para las prácticas de codificación que pueden llevar a uno a encontrar varios patrones. Si desea otro posible punto de partida, consulte Patrones y prácticas de Microsoft .

Los patrones de aprendizaje no son solo aprender algo. Aprendes lo que puedes hacer con los lenguajes de programación. Aprendí mucho sobre programación orientada a objetos solo por aprender cómo funciona un patrón ( patrón compuesto en este caso).

Como lo mencionó Oded, la mayoría de los programadores los usan a veces sin siquiera reconocerlo. La belleza de los patrones es que puede abordar problemas específicos con un patrón predefinido para que no tenga que pensar mucho en cosas arquitectónicas.

Aprenderás patrones a medida que comiences a trabajar con proyectos existentes. Existen tantos patrones para que aprendas, y no vale la pena dedicar tiempo a dominarlos todos, ya que depende del proyecto en el que estés trabajando. Cuando te encuentres con uno, aprende sobre él para ver cómo se usa.