tipos software patrones ejemplos diseño creacionales arquitectura design-patterns

design-patterns - software - patrones de diseño web



¿Cómo se aplican los patrones de diseño? (9)

Desde una perspectiva de libro, podría decir que el patrón de diseño x es aplicable en el escenario y, pero quiero profundizar un poco más aquí. Así que aquí están mis consultas:

  1. ¿Cuándo decides por primera vez que usarás patrones de diseño? ¿Todos ustedes deciden sobre patrones de diseño antes de codificar?
  2. ¿Hay algún DP que apliques después de que hayas terminado de codificar (refactorizaciones pequeñas)? ¿Aplicas DP mientras mantienes el código?
  3. ¿Cuáles son los patrones de diseño que se aplican predominantemente durante el diseño?
  4. ¿Cuáles son los DP que aplica al modificar / refactorizar el código?
  5. ¿Hay alguna sugerencia en el código (material técnico no funcional) que sugiera que debería aplicar un DP (como demasiados ifs, doble despacho, multiproceso)? Si es así, ¿podrías nombrar a los DP y sus puntos de captura?
  6. ¿Usas algún Micro-DP que te haga sentir bien con el código que has escrito (aunque otros te odian por eso: p)?

Editar:
Me gustaría agregar que leí DP a través de "Head First Design Patterns" y aunque es uno de los mejores libros para entender el patrón. No creo que haya podido hacer una transición de los ejemplos de Pizza a escenarios del mundo real.

Creo que este es uno de los libros más influyentes en DP, pero aún podemos tener un libro que pueda enumerar los diversos escenarios de negocios populares que exigen un patrón particular junto con ese patrón. Este conocimiento es todavía implícito en gran medida, creo. Tal libro sería una referencia rápida muy buena, ¿no crees?)

  1. Depende de cómo se escriba el código. Si es un proyecto grande, lo decido antes de codificar, luego de comenzar a escribir el código, si me doy cuenta de los lugares donde se deben usar los patrones de diseño, refactorizo ​​el código.

  2. Sí, como se mencionó antes.

  3. en el 99,99% de los casos: Factory Pattern , Singleton (como todo el mundo, lo uso en muchos lugares porque es fácil de implementar y, en la práctica, tiendo a eliminarlo mientras refactorizo ​​el código). Luego: Grupo de objetos (si tengo recursos que quiero reutilizar, algunos de mis proyectos son juegos y necesito una buena administración de recursos), Estrategia y Método de plantilla (porque son excelentes para disociar y sirven bien para hacer el código). fácil de extender). Entonces, el adaptador es algo para usar cuando tiene una biblioteca que quiere usar, sin confiar en ella (desacoplamiento).

  4. Igual que el de arriba, si aún no los he usado. Funciona también de la manera opuesta. Si no encuentro la razón para usar un patrón de diseño, lo elimino o lo omito mientras escribo el código (sucede todo el tiempo con singleton y de vez en cuando con las fábricas. En algún momento utilizo una fábrica que también es un singleton para proporcione los objetos que se suponía que eran objetos singletes; no estoy seguro de si es algo inteligente, pero funciona para mí).

  5. El único indicio de código que podría pensar es la cantidad de referencias que tiene para una clase. También puede usar PMD , jDepend y las reglas de arquitectura para localizar los lugares donde las clases contienen demasiadas dependencias. No estoy seguro de que esto sea un consejo de codificación. En la fase de diseño y no solo cuando decida utilizar un patrón de diseño, piense en los beneficios. Descubrí que los Principios de diseño de software son extremadamente importantes para ayudarlo a comprender cuándo y por qué (no) usar un patrón de diseño, pero son desconocidos para muchos programadores que usan patrones de diseño .

  6. No estoy seguro de a qué te refieres con Micro DP. Estoy tratando de usar DP solo cuando encuentro razones para usarlas y cuando los beneficios parecen ser más grandes que los problemas. Evito el uso excesivo porque le lleva a perder tiempo implementando y manteniendo patrones de fábrica en lugar de software real.

1 y 2

Creo que es un enfoque incorrecto para cada uno decidir ciegamente sobre un patrón favorito, o primero codificar y luego refactorizar a un patrón conocido. Cuando vea un problema, tendrá que reconocer la similitud con otros problemas que podrían resolverse utilizando patrones conocidos.

Los patrones no son un libro de cocina para el éxito; Es una regla de oro. Leer sobre casos en un libro sobre patrones puede ayudarlo a reconocer problemas, evitándole un malentendido o dos.

3: Los patrones que predominan dependen mucho del dominio. Los patrones de estado, los proxies y las fachadas son muy comunes cuando se realizan aplicaciones que se comunican mucho con otros sistemas. La aplicación GUI tiene diferentes requisitos, etc.

En mi sector (Banca): veo muchos de los siguientes patrones de GOF: Método de fábrica, Singleton, Adaptador y Fachada. Los patrones de comportamiento son más o menos muertos por las predominantes java-ee 14 capas de antipatrones que fueron en modo du jour hace 10 años.

4: Mientras refactorizas: si un patrón te ayuda, úsalo. No hay una clase de patrones que se adapten mejor al refactorizar.

5: Creo que el indicador principal para un patrón específico está más relacionado con el problema y su similitud con otros problemas que se han resuelto mediante un patrón particular. Sí, si el código huele, eso indica que podría estar necesitando una reescritura, y el problema debería analizarse nuevamente. Si bien algunos problemas son complicados y no se pueden reducir, la mayoría puede y un patrón puede ayudar a organizar un poco el problema.

Sin embargo. Como consecuencia de la observación de que los problemas complejos requieren soluciones complejas, las personas gruesas tienden a escribir código complejo; Que hay para eso. P.ej. Los patrones de estado (que me gustan) pueden complicar las cosas a niveles inimaginables si se usan en exceso.

6: A mis colegas parece gustarme, así que probablemente no estoy exagerando nada. Me siento bastante molesto por el uso excesivo de Fábricas y Métodos de fábrica en el código que no es probable que cambie o exista en diferentes implementaciones al mismo tiempo, y si finalmente se modificará, será necesario volver a escribirlo de todos modos. Eso es solo una pérdida de tiempo, y complica el código y retrasa la búsqueda de errores.

Creo que hay una tendencia, al menos para aquellos que recién aprenden patrones de diseño, a aplicar un patrón en exceso; Cuando tienes un martillo, todo empieza a parecer un clavo. Una mejor manera de hacerlo es considerar las alternativas para una API y sus respectivas ventajas y compensaciones, y luego seleccionar la que sea apropiada. Un patrón de diseño es más una ayuda terminológica que permite a los desarrolladores transmitir lo que están haciendo en lugar de proporcionar una guía de cómo se debe escribir el código. Es decir, algunas cosas se repiten en el código y es más fácil decirle a su compañero de trabajo que usó una fábrica que a la explicación de que tenía un objeto que pasó y creó otros objetos ... pero solo porque existe la noción de fábricas no significa que debas intentar convertir todo lo que ves en una fábrica. ¿Tener sentido?

En mi experiencia, depende de la metodología y el nivel del diseño inicial en cuanto a cuándo se aplican los patrones. Por lo general, en un proceso ágil veré que un patrón emerge con bastante rapidez a medida que se desarrolla la intención del código y luego se refactoriza en consecuencia.

El riesgo de afirmar que la prueba de la unidad obvia reduce mucho el riesgo, pero cuanto antes lo haga, mejor. Nunca he hecho un gran refactor de código en el apoyo para implementar un nuevo patrón, ya que el esfuerzo involucrado rara vez ha mostrado un beneficio significativo. A menos que el proyecto esté a punto de pasar a una nueva fase de desarrollo.

Las refactorizaciones pequeñas contenidas en uno o dos métodos son bastante comunes durante la vida útil de un proyecto, pero tienen el pretexto de que no existe tal cosa como "código completo" :)

No olvide el libro Design Patters , puede que cubra C ++ pero no importa, son todos los patrones. Además el libro es muy bueno.

Y no aprendes patrones para implementarlos, esa es la manera incorrecta, aprendes entonces para poder hablar sobre el código con otros programadores. Es más una extensión de su lenguaje normal que cualquier otra cosa. Úselo en su código cuando sea necesario, pero no antes :-)

OMI, no hay reglas o situaciones comunes. Los patrones de diseño se utilizan cuando son apropiados, a veces lo sabes al diseñar, a veces al codificar, a veces al refactorizar.

La mayoría de las veces no "aplico un patrón de diseño" uno a uno. Ellos necesitan adaptación. Los patrones de diseño son como un catálogo de experiencias. Solo conoce algunos patrones comunes o típicos y los cambia a la solución que necesita. (Nota: son patrones, no soluciones.)

Tomaré un enfoque diferente aquí y no mencionaré los libros ni abordaré todos esos puntos por separado.

En mi caso, el mejor impacto lo conseguí al respirar SOLID . Imho, puede relacionar muchos escenarios y patrones con esos principios, y seguir una mentalidad de base de código en evolución junto con ellos generalmente revela las necesidades de todos esos otros patrones para usted.

En cuanto a pistas, métodos largos => refactor. Incluso si solo se está moviendo a métodos en la misma clase, ya que generalmente ese paso intermedio revela el siguiente movimiento.

Un patrón de diseño describe una solución general reutilizable a un problema recurrente en un contexto dado. Usted aplica un patrón cuando identifica problemas de diseño que un patrón puede resolver. Esto puede suceder durante el diseño inicial, durante la codificación, durante el mantenimiento, etc. No hay una receta absoluta, OMI.

Ver también