¿Cuáles son los patrones de diseño con los que debería estar completamente familiarizado? ¿Y cuál es un ejemplo fácil para cada uno de ellos?¿Qué tan importantes son los patrones de diseño en el desarrollo web?
Soy un desarrollador web (uso Django y estoy familiarizado con la separación de la lógica), pero trabajo en una empresa de aplicaciones de escritorio. Siempre están hablando de singleton, y lo olvido ... ¡pero no me deja ninguna pista!
Forget Singleton. Es confuso y rara vez es necesario.
Learn Estado, Estrategia y Comando. Se usan todo el tiempo.
El estado es para cualquier cosa que tenga una lógica que dependa del estado del objeto. En resumen, cada instrucción if podría posiblemente realizarse mejor a través del Estado. Seriamente. Demasiadas declaraciones if son un olor a código e indican que hay un procesamiento con estado disperso por todos lados.
La estrategia es para cualquier procesamiento "plug-in" o "expansión" u "opción".
El comando es para cualquier conjunto de acciones extensible (y composable). Copia de seguridad de restauracion. Table Drop, Create, Index, Populate. Validar, Cargar, Resumir, Informar. Cualquiera de esas cosas similares a comandos que se pueden juntar de diferentes maneras, diferentes órdenes, etc., probablemente debería hacerse con un diseño formal de Command.
+1 para el patrón de estrategia. Lo más útil que he aprendido, diseño de patrón sabio. – GSto
-1 por decir 'olvidar' Singleton. Sí, se usa en exceso y tiende a actuar como una estática global, lo cual es horrible, pero uno necesita saber de qué se trata, y ES ocasionalmente necesario. Ciertamente, no aconsejaría a nadie que lo ignore o que no esté familiarizado con un patrón tan ampliamente utilizado. Es esencial estar familiarizado con él, si no por otra razón que no sea poder argumentar de manera efectiva en las reuniones de diseño, por qué no deberíamos usarlo. –
@DaveSims Estoy de acuerdo contigo. Mi ejemplo favorito es el objeto de conexión a la base de datos. Si tenemos que pasarlo a cada método en el sistema, nos volveríamos locos. – dotslash
MVP o MVC
Model View Presenter o Model View Controller
Más patrones architecural pero neverless, que son una combinación de patrones de diseño.
Toda una declaración audaz. Veo montones de escenarios en los que el MVC sería inadecuado o simplemente indirecto inútil. –
No estoy de acuerdo. Para la capacidad de prueba, y con marcos tales como ASP.NET MVC y otros, probablemente sea más doloroso no seguir tales patrones. – Finglas
Si bien "ninguna aplicación web debería estar sin ellos" puede ser demasiado audaz, yo diría que "ningún desarrollador de aplicaciones web debería conocerlos". –
Honestamente, los patrones son importantes, pero saber cuándo usarlos es igual de importante. Nunca habrá una respuesta establecida, es algo que necesitas sentir por ti mismo. Las personas que pelean porque es un absoluto en el que siempre debes usarlas o no usarlas nunca son incorrectas. Los patrones de diseño son una herramienta. Sugeriría buscar en Amazon.com un libro en cualquier idioma en el que esté escribiendo que trate específicamente los patrones de diseño. Sé que hay uno escrito para Ruby on Rails que es genial, aunque no recuerdo el nombre, también hay uno para Java llamado Head First Design Patterns, y para C# escrito por Bob y Micah Martin que es excelente. Lea cualquiera de los que corresponda al idioma con el que esté más familiarizado. Incluso si no usa todos los patrones, es bueno comprender cómo funcionan y cuándo serán útiles.
MVVM es uno más nuevo que he visto usado con Silverlight. Es un poco demasiado, pero parece efectivo.
¿No se refiere a MVVM o Model View ViewModel? Si no es nuevo para mí. – Finglas
Conocer los patrones de diseño no será de mucha utilidad hasta que sepa por qué son la mejor estrategia para un problema determinado. Aprender patrones de diseño desde el principio probablemente sea correcto, excepto que ha olvidado todas las formas "incorrectas" de resolver ese problema, lo que a su vez significa que puede estar perdiendo una diferencia sutil en cuándo usar el patrón dado y cuándo no usarlo. .
Lo único peor que las personas que mantienen sus viejas costumbres y no se molestan en aprender de la manera adecuada, es la gente que aprende de la manera correcta y no se molesta en aprender por qué es apropiado.Y lo siguen aplicando a cosas que no deberían aplicarse, porque simplemente no lo saben mejor.
Así que mi punto es que si eres nuevo en el desarrollo web, no te metas demasiado en el patrón de diseño (aunque es una buena exageración). Aprende haciendo cosas tú mismo. Cuando haya alcanzado un cierto nivel, lea los patrones de diseño y vea dónde se podrían haber aplicado para mejorar su código.
ESA es la forma de aprenderlos correctamente. No es como ser forzado a correr antes de que puedas caminar.
Para aplicaciones web, entender al menos en un nivel rudimentario los patrones descritos en Patrones de la arquitectura de aplicaciones empresariales me ha resultado valioso. Los patrones de Gang of Four también valen la pena.
Pero yo diría que simplemente no necesita el conocimiento enciclopédico de los patrones para comenzar. Una comprensión superficial le ayudará a comprender dónde mirar cuando comience a encontrar fricción entre sus ideas/problemas comerciales y su código. Tuve un par de viajes de fin de semana que me permitieron analizar estos dos libros en su totalidad, pero todavía encuentro la información detallada en la sección de patrones más útil como referencia que como conocimiento de fondo.
Leer solo las secciones "Parte 1" del GoF o PoEAA le ayudará mucho más que aprender tres o cuatro patrones en profundidad, porque sabrá dónde buscar cuando tenga problemas que describan. Y puede buscar los detalles de la mayoría de los patrones que describen en línea.
Los patrones de GoF que uso directa o indirectamente, a menudo inconscientemente, en el desarrollo web, incluyen: Observador, Comando, Compuesto, Estado, Estrategia. Normalmente no utilizo Singleton, excepto como cliente de herramientas de registro y localización de servicios/inyección de dependencias. Los patrones PoEAA que utilizo regularmente, generalmente inconscientemente o incidentalmente como parte de la estrategia de acceso a datos o marco web que estoy usando, son Active Record, Application Controller, Data Mapper, Modelo de dominio, Gateway, Lazy Load, Layer Supertype, Page Controlador, Vista de plantilla y Objeto de valor. Eso no es exhaustivo; estos son solo algunos de los que aparecieron en la mente.
La mayoría de estos son probablemente más útiles aprendidos comenzando con un marco de desarrollo web obstinado, como Rails, Django o Castle Monorail, que en el resumen. Después de todo, los patrones fueron identificados y extraídos de miles de experiencias exitosas de desarrollo de aplicaciones, no inventadas y luego pegadas porque parecían inteligentes.
Es muy fácil emocionarse demasiado por el conocimiento superficial de uno o dos patrones y luego ver "solo clavos" por cada problema que vea poco después e intentar convertir un patrón que no se ajusta bien en una solución porque entiendes cómo funciona
Entonces, aprende patrones, sí; obtenga una visión general superficial de las motivaciones de todos los que se usan comúnmente, pero no sienta que tiene que esperar para escribir un código serio hasta que comprenda una lista arbitraria de ellos.
comunidad wiki .... – jldupont
Seguro, wiki de la comunidad. – TIMEX
Solo consígase el libro más relevante y hágalo todo. –