Usar diferentes patrones para características similares

Soy el único desarrollador de un proyecto que, como cualquier proyecto de software, puede ser tomado por otra persona en el futuro.

Digamos que usé el patrón X para implementar la característica A. Después de desarrollar y terminar la característica, me doy cuenta de que podría implementar la misma característica usando el patrón Y, del que acabo de enterarme. Pero la función A funciona bien y la refactorización de X a Y lleva mucho tiempo y ofrece pocos beneficios.

Entonces es hora de implementar la función B. Es similar a A, pero esta vez quiero aprovechar esta oportunidad para jugar con el patrón Y. Estoy contento con el resultado final, mejor que cuando hago la función A, pero ahora mi código usa dos diferentes patrones, X e Y, para características similares.

Pero no hay una razón real para usar diferentes patrones, excepto por el hecho de que al construir la función, la IA no tenía la habilidad suficiente para usar el mismo patrón que para la función B.

Tenga en cuenta que esta pregunta no se trata de elegir el patrón correcto para un problema dado ; Se trata de dos patrones coexistentes en la base del código para resolver problemas similares, que podrían reducirse a uno dado el tiempo suficiente para refactorizar.

• ¿Ese código huele?
• ¿Cuáles son las desventajas de mantener el código fuente como este?
• ¿Debería seguir usando solo un patrón? es decir, ¿refactoriza A para usar Y o sigue usando X cuando escribe B?
• ¿Cómo, en la fuente, puedo comunicar que la razón por la que hay dos patrones diferentes para características similares no es esencialmente ninguna razón?
• ¿Me estoy preocupando demasiado por lo que el próximo desarrollador piensa sobre mi código?

Si el patrón X e Y resuelven el mismo problema y ninguno de los dos es objetivamente mejor, entonces debe decidir sobre uno y atenerse a él. Si es posible, debe tratar de resolver el mismo problema de la misma manera de manera consistente.

No te preocupes demasiado, sino que es un olor a código serio que definitivamente debes manejar y limpiar.

Las desventajas de tener diferentes soluciones para el mismo problema en una base de código:

• tomará el doble de tiempo entender el código
• La modificación del código demorará el doble cuando cambie parte del comportamiento que involucra el patrón
• tendrás el doble de errores
• colegas actuales y futuros te odiarán

Estoy de acuerdo con la respuesta de JacquesB . Yo agregaría, respondiendo a otras de sus preguntas, que si en este momento tiene los dos patrones coexistiendo, y no ha tenido el tiempo (todavía) de refactorizar su aplicación para usar la que consideró la mejor, debería poner eso en sus comentarios en la clase "ofensiva" (la que se refactorizará). De esta manera, es evidente para el futuro desarrollador (usted u otra persona) que todavía hay algo de deuda que pagar.

Finalmente, la principal desventaja de mantener una base de código como esta es la complejidad añadida, pero innecesaria. ¡Definitivamente quieres evitar la complejidad innecesaria a toda costa!

No juegues en la base de código. Los prototipos de escritura hacen que pueda encontrar las ventajas y desventajas de un patrón / diseño sobre los otros.

Puede resultar que lo que intuitivamente se puede reducir, en realidad puede ser más complejo que tener 2 patrones diferentes.

Espere lanzar una gran parte del código desarrollado para el prototipo.

Si esto es o no un olor a código depende realmente de cuán similares sean el problema A y el problema B. La respuesta de JacquesB parece suponer que son muy similares, y que si cambia el problema A (para solucionar un error, por ejemplo), también tendrá que cambiar el problema B al mismo tiempo. JaqueB podría estar en lo cierto, pero también podría ser el caso de que A y B cambien independientemente porque no son tan similares. En esa situación, es poco probable que se describan las desventajas.

Según su descripción, suena como un olor a código (Duplicación), pero es difícil decir cuán maloliente es el olor. Por ejemplo, si A usa el Método de plantilla y B usa la Estrategia, los dos problemas podrían ser muy diferentes a pesar de los patrones reflejados que se usan. Esperaría y vería acercarse. En el caso de que aparezca el problema C y sea como A y B, entonces refactorizaría A para que sea consistente con B y luego crear C debería ser muy simple. Si hay un error en A, también me gustaría refactorizarlo para que coincida con B, luego corregir el error. En el caso de que nada cambie entonces ... no importa ¿no?

Tener múltiples formas de resolver problemas similares en una base de código es una realidad. Incluso en el caso de que sea el único desarrollador, aprenderá cosas nuevas y tendrá nuevos conocimientos, por lo que sus soluciones cambiarán. Como reconoce correctamente, necesita corregir estas imperfecciones mientras proporciona valor. El rediseño (que es lo que realmente estás haciendo cuando cambias un patrón) de código que nunca cambiará de nuevo no proporciona valor. La única forma real de saber que va a cambiar es tener que hacer el cambio, por lo que esperaría un problema C.

No, puede tener múltiples patrones utilizados en una sola base de código.

Sin embargo, si está implementando un componente y está exponiendo una forma de usarlo que sigue un patrón, entonces probablemente sea mejor seguirlo. Digamos, por ejemplo, que estoy usando el patrón de construcción para mi cliente de consulta REST, pero luego implemento uno de los recursos de manera diferente. Eso va a confundir a la gente.