Sono sicuro che ci sia un nome per questo anti-pattern da qualche parte; tuttavia non conosco abbastanza bene la letteratura anti-pattern per saperlo.
Considera il seguente scenario:
or0 è una funzione membro in una classe. Nel bene o nel male, è strongmente dipendente dalle variabili dei membri della classe. Il programmatore A arriva e ha bisogno di funzionalità come or0 ma piuttosto che chiamare or0 , il programmatore A copia e rinomina l'intera classe. Suppongo che lei non chiami or0 perché, come ho detto, dipende strongmente dalle variabili membro per la sua funzionalità. O forse è una programmatrice junior e non sa come chiamarla da un altro codice. Quindi ora abbiamo or0 e c0 (c per copia). Non posso assolutamente criticare il programmatore A per questo approccio: tutti noi abbiamo tempi di consegna molto stretti e abbiamo il codice per fare il lavoro.
Diversi programmatori mantengono or0 quindi ora è la versione orN . c0 è ora la versione cN . Sfortunatamente la maggior parte dei programmatori che hanno mantenuto la classe contenente or0 sembravano completamente inconsapevoli di c0 - il che è uno degli argomenti più forti a cui posso pensare per la saggezza del principio DRY. E potrebbe anche esserci stato un mantenimento indipendente del codice in c . In entrambi i casi, sembra che or0 e c0 siano stati mantenuti indipendenti l'uno dall'altro. E, gioia e felicità, si verifica un errore in cN che non si verifica in orN .
Quindi ho alcune domande:
1.) Esiste un nome per questo anti-pattern? Ho visto accadere così spesso che troverei difficile credere che non si tratti di un anti-modello con un nome.
2.) Posso vedere alcune alternative:
a.) Correggere orN per prendere un parametro che specifica i valori di tutte le variabili membro di cui ha bisogno. Quindi modifica cN per chiamare orN con tutti i parametri necessari passati.
b.) Prova a trasferire manualmente le correzioni da orN a cN . (Intendiamoci, non voglio farlo ma è una possibilità realistica).
c.) Recopy orN a cN - di nuovo, schifo ma lo elenco per completezza.
d.) Cerca di capire dove cN è rotto e poi ripararlo indipendentemente da orN .
L'alternativa a sembra la soluzione migliore a lungo termine, ma dubito che il cliente mi consenta di implementarla. Mai tempo o denaro per sistemare le cose, ma sempre tempo e denaro per riparare lo stesso problema 40 o 50 volte, giusto?
Qualcuno può suggerire altri approcci che forse non ho considerato?
Se tu fossi al mio posto, quale approccio prenderesti? Se ci sono altre domande e risposte qui su queste linee, si prega di inviare link a loro. Non mi dispiace rimuovere questa domanda se si tratta di un dupe ma la mia ricerca non ha ancora trovato nulla che indirizzi ancora questa domanda.
EDIT: ringrazia tutti per tutte le risposte ponderate.
Ho chiesto un nome per l'anti-pattern in modo da poterlo cercare ulteriormente da solo. Sono sorpreso che questa particolare cattiva pratica di codifica non abbia un nome "canonico" per questo.
