Utilizzo di modelli diversi per funzionalità simili

Se il modello X e Y risolvono lo stesso problema e nessuno dei due è oggettivamente migliore, allora dovresti decidere su uno e attenersi ad esso. Se è possibile, dovresti sforzarti di risolvere lo stesso problema nello stesso modo in modo coerente.

Sei non preoccupato troppo, piuttosto è un odore di codice serio che dovresti assolutamente gestire e ripulire.

Gli svantaggi di avere soluzioni diverse allo stesso problema in un codice base:

• ci vorrà il doppio del tempo per capire il codice
• ci vorrà il doppio del tempo per modificare il codice quando si modifica un comportamento che coinvolge il modello
• avrai il doppio di bug
• i colleghi attuali e futuri ti odieranno

Sono d'accordo con la risposta di JacquesB. Vorrei aggiungere, rispondendo ad altre domande, che se in questo momento i due modelli coesistono e non hanno ancora il tempo (ancora) di rifattorizzare la tua applicazione per utilizzare quella che hai trovato la migliore, dovresti mettere che nei tuoi commenti nella classe "offendente" (quella da refactoring). In questo modo, è evidente al futuro sviluppatore (tu o qualcun altro) che c'è ancora del debito da pagare.

Infine, lo svantaggio principale di mantenere un codice base come questo è la complessità aggiunta, ma non necessaria. Sicuramente vuoi evitare la complessità non necessaria a tutti i costi!

Non giocare nella base di codice. Scrivi prototipi che puoi trovare i vantaggi e i disavaggi di un modello / disegno rispetto agli altri.

Potrebbe risultare che ciò che intuitivamente può essere ridotto può essere in realtà più complesso di due modelli diversi.

Aspettatevi di gettare una buona parte del codice sviluppato per il prototipo.

Indipendentemente dal fatto che si tratti di un codice, l'odore dipende in realtà solo da come sono simili i problemi A e B. La risposta di JacquesB sembra presumere che siano molto simili e che se cambi il problema A (per correggere un bug per esempio) dovrai anche cambiare il problema B allo stesso tempo. JaqueB potrebbe avere ragione, ma potrebbe anche accadere che A e B cambino in modo indipendente perché non sono poi così simili. In questa situazione è improbabile che vengano descritti gli aspetti negativi.

In base alla tua descrizione sembra un po 'di odore di codice (Duplicazione), ma è difficile dire quanto puzzolente sia l'odore. Ad esempio, se A utilizza Metodo Metodo e B usa Strategia, i due problemi potrebbero essere molto diversi, nonostante i pattern di mirroring utilizzati. Vorrei aspettare e vedere l'approccio. Nel caso in cui il problema C arrivi e sia come A e B, allora il refactor A deve essere coerente con B e quindi creare C dovrebbe essere molto semplice. Se c'è un bug in A vorrei anche rifattarlo per abbinare B, quindi correggere il bug. Nel caso in cui nulla cambi allora .... non importa, vero?

Avere più modi di risolvere problemi simili in un codebase è un dato di fatto. Anche nel caso in cui tu sia l'unico sviluppatore, imparerai cose nuove e avrai nuove intuizioni, quindi le tue soluzioni cambieranno. Come si riconosce correttamente è necessario correggere queste imperfezioni fornendo valore. La riprogettazione (che è ciò che stai facendo davvero quando cambi un pattern) il codice che non cambierà mai non fornisce alcun valore. L'unico vero modo per sapere che cambierà è in realtà dover fare il resto, ed è per questo che aspetterei un problema C.

No, puoi avere più pattern usati in una singola base di codice.

Tuttavia, se stai implementando un componente e stai esponendo un modo di usarlo che segue un pattern, probabilmente è meglio attenersi a quello. Supponiamo, ad esempio, che io stia usando il modello di builder per il mio client di query REST, ma poi implemento una delle risorse in modo diverso. Questo confonderà le persone.