Debe echar un vistazo a los olores de código y las recetas de refactorización.
Sé que no estoy respondiendo exactamente su pregunta, porque de esta manera no está refactorizando explícitamente los Patrones de diseño. Pero no mezcle refactorización y patrones de diseño.
Si sigue los olores de código y refactoriza el código en consecuencia para hacer que los olores desaparezcan, los Patrones de diseño pueden aparecer eventualmente … o no. Lo que obtendrá es una solución a su problema, sea lo que sea (y una solución fácil de mantener).
- ¿Hay algún buen ejemplo de especificaciones funcionales en un proyecto web para aprender?
- ¿Con qué frecuencia te frustras al codificar?
- ¿Es demasiado tarde para comenzar a estudiar Selenium en Java ahora, desde la perspectiva de un trabajo de prueba de software en la India?
- Cómo valorar los servicios de desarrollo de software en Sudáfrica
- ¿Los ingenieros marinos obtienen el mismo respeto que los ingenieros de software?
Los patrones de diseño no son realmente “soluciones listas para usar”. Son más ejemplos de soluciones para resolver problemas específicos. Y no estoy seguro al principio, realmente evolucionaron de problemas reales en la naturaleza a través de la refactorización. Algunos pueden haber aparecido de esa manera, pero creo que otros simplemente salieron de la mente de la gente de GoF.
Intentar solucionar su problema para que coincida con algunos patrones de diseño de destino requiere problemas. Trabajé con algunas personas que intentaron hacer eso y eso generó grandes problemas para los proyectos (complejidad inútil).
Por lo general, es mucho mejor usar Patrones de diseño como un lenguaje común compartido para describir su solución a los demás. Ambos pueden describir cómo la solución implementada es como un patrón de diseño bien conocido y también cómo difiere de él.