Como estudiante de TI, uno de nuestros maestros me dio una visión general sobre los patrones de diseño. Comprendí para qué son, pero algunos aspectos todavía me siguen molestando.

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

Hablando de experiencia, he tenido algunos problemas al programar, cosas que no pude resolver por un tiempo, pero Google y algunas horas de investigación resolvieron mi problema. Si en algún lugar de la web encuentro una manera de resolver mi problema, ¿es este un patrón de diseño? ¿Lo estoy usando?

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

ACTUALIZACIÓN: Creo que cuando pregunto si los programadores los usan, pregunto si cuando tiene un problema para resolver piensa "Oh, debería usar ese patrón".

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

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

Más recientemente, encuentro que tener en cuenta principios como el Principio de responsabilidad única y escribir primero las pruebas 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 trato de forzarlos en el código. Si surge un patrón de visitante, probablemente se deba a que he reestructurado la duplicación, no porque haya pensado con anticipación en las similitudes de representar un árbol en lugar de sumar sus valores.

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

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

Sin embargo, en el trabajo diario, uno no comienza a programar con un patrón en mente: 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 iterador integrado en C # con la foreachpalabra clave.

A veces ya conoce el patrón que utilizará como una solución común al problema en cuestión (por ejemplo, el patrón de repositorio ; ya sabe que desea representar sus datos como una colección en memoria).

Como lo implica la respuesta pdr vinculada: los patrones de diseño son nombres dados a las cosas que la gente estaba 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 dan una idea de las soluciones que las personas han encontrado que funcionan, por lo que puede aprovechar años de experiencia y prueba y error.

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

Si resulta que usa uno o más patrones existentes, entonces genial, tiene nombres ya preparados que facilitarán que otros entiendan su código.

En general, 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 abusados ​​y mal utilizados sin que la gente considere si son un buen diseño. Los patrones no son átomos. El código no está compuesto por 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 Gran Bola de Barro . Por lo general, comienzan con arquitecturas bien diseñadas, pero generalmente terminan aquí, especialmente si comienzan a pensar "debemos usar patrones de diseño" en todo el lugar y refactorizar sin piedad.

los usas?

Sí, los programadores experimentados definitivamente lo hacen. Puede evitar usar la mayoría de los patrones de diseño (excluyendo cosas simples simples) por ahora; pero cuanto más programe y más complejos sistemas construya, más sentirá la necesidad de usar patrones de diseño. Si todavía 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 este 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). Lo que puede haber encontrado puede no ser 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?

Si. Los patrones de diseño encarnan el axioma "es mejor prevenir que curar". Si puede detectar un problema de diseño próximo en particular de antemano, puede evitar rediseños masivos para acomodar 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 crea su aplicación.

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

Como eres estudiante, probablemente no hayas visto los problemas típicos que inspiran los patrones de diseño. Le recomiendo que mire los patrones de diseño de Head First . Primero presentan un problema de diseño y luego muestran cómo un patrón 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 tomé un libro o intenté leer un tutorial sobre el tema, mis ojos se volvieron vidriosos y realmente no aprendí nada práctico sobre ellos.

No puedo creer que haya admitido eso en público. Creo que probablemente acabo de perder cualquier crédito 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, no importa cuán populares sean o si otros programadores los 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 en ellos cuando es al revés.

Recuerde que las convenciones de diseño de patrones de diseño tienen 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 donde encontrará patrones de diseño aplicados. Un ejemplo que me viene a la mente es Joomla: encontrará singletons , observadores . Las bibliotecas GUI tendrán el patrón de decorador , el patrón de comando implementado y tal vez incluso el peso mosca .

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

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

Solo aprende para cuando llegue el momento

Aprenderlos, conocerlos, obsesionarse con ellos y cuando llegue el momento sabrá cómo resolver el problema de programación x, ya será un mejor programador.

Convertirse en arquitecto

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

He programado durante aproximadamente 7 años en C ++ y aprendí patrones hace aproximadamente 2 años. La mayoría de los patrones probablemente tengan algunas aplicaciones, pero en mi uso, algunos son mejores que otros. Tienes que pensar por qué los estás usando.

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

Sin embargo, el método de fábrica ha sido extremadamente útil, basado en el polimorfismo que proporciona. Olvidé quién lo dijo, pero la afirmación "la reutilización significa que el código antiguo puede usar 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 Observador ha sido útil en algunos casos, a veces no. En ocasiones, debe predecir la complejidad para determinar si la complejidad del patrón del Observador vale la pena. Tenemos un programa que utiliza alrededor de 10 suscriptores y podría haber muchos más, por lo que el patrón de observador / suscriptor ha sido útil. Sin embargo, otro programa tiene dos pantallas GUI. Implementé el patrón de observación para este programa, y ​​ha sido en gran parte innecesario, simplemente porque agregó complejidad y no preveo agregar más pantallas.

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

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

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

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

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 en los años venideros.

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

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

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

No, ese no es un patrón de diseño para mí. Un patrón de diseño tiende a tener algún arreglo 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, ¿se encuentran ustedes (programadores) buscando patrones (¿dónde se supone que debo mirar por cierto?) Cuando comienzan el desarrollo? Si es así, este es ciertamente un hábito que debo comenzar a adoptar.

A 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 los Patrones y prácticas de Microsoft .

Aprender patrones no es solo aprender algo. Aprendes lo que puedes hacer con los lenguajes de programación. Yo mismo aprendí mucho sobre programación orientada a objetos simplemente aprendiendo cómo funciona un patrón (el patrón compuesto en este caso).

Como 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á patrones cuando comience a trabajar con proyectos existentes. Hay muchos patrones para que aprendas, y no vale la pena dominarlos, ya que depende del proyecto en el que estés trabajando. Cada vez que te encuentres con uno, aprende sobre él para ver cómo se usa.