Usando padrões diferentes para recursos semelhantes

Sou o único desenvolvedor de um projeto que, como em qualquer projeto de software, pode ser realizado por outra pessoa no futuro.

Digamos que usei o padrão X para implementar o recurso A. Depois de desenvolver e finalizar o recurso, percebo que poderia implementar o mesmo recurso usando o padrão Y, sobre o qual acabei de aprender. Mas o recurso A está funcionando bem e a refatoração de X para Y consome tempo e oferece pouco benefício.

Chegou a hora de implementar o recurso B. É semelhante ao A, mas desta vez quero aproveitar esta oportunidade para brincar com o padrão Y. Estou feliz com o resultado final, melhor do que ao executar o recurso A, mas agora meu código usa dois padrões diferentes, X e Y, para recursos semelhantes.

Mas não há motivo real para usar padrões diferentes, exceto pelo fato de que ao criar o recurso AI não havia habilidade suficiente para usar o mesmo padrão do recurso B.

Observe que esta pergunta não é sobre a escolha do padrão certo para um determinado problema ; trata-se de dois padrões coexistentes na base de código para resolver problemas semelhantes, que podem ser reduzidos a um dado tempo suficiente para refatorar.

• Esse código está com cheiro?
• Quais são as desvantagens de manter o código-fonte assim?
• Devo continuar usando apenas um padrão? ou seja, refator A para usar Y ou continuar usando X ao escrever B?
• Como, na fonte, posso comunicar que a razão pela qual existem dois padrões diferentes para recursos semelhantes é essencialmente nenhuma razão?
• Estou me preocupando demais com o que o próximo desenvolvedor pensa sobre o meu código?

Se os padrões X e Y resolverem o mesmo problema e nenhum for objetivamente melhor, você deverá escolher um e cumpri-lo. Se for possível, você deve tentar resolver o mesmo problema da mesma maneira de maneira consistente.

Você não está se preocupando muito, é um cheiro sério de código que você definitivamente deve manipular e limpar.

As desvantagens de ter soluções diferentes para o mesmo problema em uma base de código:

• levará o dobro do tempo para entender o código
• levará o dobro do tempo para modificar o código quando você alterar parte do comportamento que envolve o padrão
• você terá o dobro de bugs
• colegas atuais e futuros vão te odiar

Eu concordo com a resposta de JacquesB . Eu acrescentaria, abordando outras de suas perguntas, que se agora você tem os dois padrões coexistentes e ainda não teve tempo (ainda) de refatorar seu aplicativo para usar o que você achou melhor, você deve colocar isso em seus comentários na classe "ofensiva" (a ser refatorada). Dessa forma, é evidente para o futuro desenvolvedor (você ou outra pessoa) que ainda há alguma dívida a ser paga.

Finalmente, a principal desvantagem de manter uma base de código como essa é a complexidade adicionada, mas desnecessária. Você deseja definitivamente evitar complexidade desnecessária a todo custo!

Não jogue na base de código. Os protótipos de gravação fazem com que você possa encontrar as vantagens e desvantagens de um padrão / design sobre o (s) outro (s).

Pode acontecer que o que intuitivamente pareça ser reduzido, pode ser realmente mais complexo do que ter dois padrões diferentes.

Espere lançar uma maneira muito do código desenvolvido para o protótipo.

Se este é um cheiro de código ou não, é realmente dependente de quão similares são os problemas A e B. A resposta de JacquesB parece assumir que elas são muito semelhantes e que se você alterar o problema A (para corrigir um bug, por exemplo), também precisará alterar o problema B ao mesmo tempo. JaqueB pode estar certo, mas também pode ser que A e B mudem independentemente, porque não são tão parecidos. Nessa situação, é improvável que você tenha as desvantagens descritas.

Com base na sua descrição, parece um pouco de cheiro de código (Duplicação), mas é difícil dizer o quão fedido é o cheiro. Por exemplo, se A usa o Método de modelo e B usa Estratégia, os dois problemas podem ser muito diferentes, apesar dos padrões de espelhamento serem usados. Eu esperaria e veria a abordagem. Caso o problema C apareça e seja como A e B, refatoraria A para ser consistente com B e, em seguida, criar C seria muito simples. Se houver um erro em A, eu também gostaria de refatorá-lo para corresponder a B, em seguida, corrija o erro. No caso de nada mudar então ... não importa, não é?

Ter várias maneiras de resolver problemas semelhantes em uma base de código é um fato da vida. Mesmo no caso de você ser o único desenvolvedor, você aprenderá coisas novas e terá novas idéias, para que suas soluções mudem. Como você reconhece corretamente, você precisa corrigir essas imperfeições enquanto fornece valor. Redesenhar o código (que é o que você realmente faz quando altera um padrão) que nunca mais será alterado não fornece valor. A única maneira real de saber que isso vai mudar é realmente fazer a alteração, e é por isso que eu esperaria por um problema C.

Não, você pode ter vários padrões usados ​​em uma única base de código.

No entanto, se você estiver implementando um componente e estiver expondo uma maneira de usá-lo que segue um padrão, provavelmente é melhor manter o mesmo. Digamos, por exemplo, estou usando o padrão do construtor para o meu cliente de consulta REST, mas implemento um dos recursos de maneira diferente. Isso vai confundir as pessoas.