Cercherò di dare una risposta contro tale utilizzo, dopo aver visto e lavorato su questo anche in uno dei miei progetti.
Leggibilità del codice
Prima di tutto, considera che la leggibilità del codice è importante e questa pratica è contraria. Qualcuno legge un pezzo di codice e diciamo solo che ha una funzione doSomething(Employee e). Questo non è più leggibile, perché a causa di 10 Employeeclassi diverse esistenti in pacchetti diversi dovrai prima ricorrere alla dichiarazione di importazione per scoprire quale sia il tuo input.
Questa, tuttavia, è una visione di alto livello e spesso abbiamo scontri di nomi apparentemente casuali, che nessuno si preoccupa o addirittura trova, perché il significato può essere derivato dal codice rimanente e in quale pacchetto ci si trova. Quindi si potrebbe anche discutere che, a livello locale, non vi è alcun problema, perché ovviamente se si vede Employeeall'interno di un hrpacchetto è necessario sapere che stiamo parlando di una visione delle risorse umane del dipendente.
Le cose si rompono non appena lasci questi pacchetti. Una volta che lavori in un modulo / pacchetto / etc diverso e hai bisogno di lavorare con un dipendente, stai già sacrificando la leggibilità se non ne qualifichi completamente il tipo. Inoltre, avere 10 Employeeclassi diverse significa che il completamento automatico del tuo IDE non funzionerà più e dovrai scegliere manualmente dal tipo di dipendente.
Duplicazione del codice
A causa della natura stessa di ciascuna di queste classi in relazione tra loro, il tuo codice è destinato a deteriorarsi a causa di molte duplicazioni. Nella maggior parte dei casi, avrai qualcosa come il nome di un dipendente o un numero di identificazione, che ciascuna delle classi deve implementare. Anche se ogni classe aggiunge il proprio tipo di vista, se non condividono i dati dei dipendenti sottostanti, si finirà con enormi masse di codice inutile, ma costoso.
Complessità del codice
Cosa può essere così complesso che potresti chiedere? Dopotutto, ciascuna delle classi può mantenerlo semplice come vuole. Ciò che diventa veramente un problema è come propagare i cambiamenti. In un software ragionevolmente ricco di funzionalità potresti essere in grado di modificare i dati dei dipendenti e vuoi rifletterli ovunque. Di 'che una donna si è appena sposata e devi rinominarla da XaYa causa di ciò. Abbastanza difficile da fare proprio ovunque, ma ancora più difficile quando hai tutte queste classi distinte. A seconda delle altre scelte progettuali, ciò può facilmente significare che ciascuna delle classi deve implementare il proprio tipo di ascoltatore o tale per essere informato delle modifiche - che si traduce sostanzialmente in un fattore applicato al numero di classi che devi affrontare . E ovviamente più duplicazione del codice e minore leggibilità del codice. Fattori come questo possono essere ignorabili nell'analisi della complessità, ma sono sicuramente fastidiosi se applicati alle dimensioni della tua base di codice.
Comunicazione del codice
Oltre ai problemi di cui sopra con la complessità del codice, che sono anche correlati alle scelte di progettazione, si sta anche riducendo la chiarezza di progettazione di livello superiore e si perde la capacità di comunicare correttamente con gli esperti del dominio. Quando si discute di architettura, progetti o requisiti, non si è più liberi di fare dichiarazioni semplici come given an employee, you can do .... Uno sviluppatore non saprà più cosa employeesignifichi davvero a quel punto. Anche se un esperto di dominio lo saprà ovviamente. Noi tutti facciamo. una specie di. Ma in termini di software non è più così facile comunicare.
Come sbarazzarsi del problema
Dopo esserti reso conto di questo e se la tua squadra concorda sul fatto che si tratta di un problema abbastanza grande da affrontare, dovrai trovare un modo per affrontarlo. In genere, non è possibile chiedere al proprio responsabile di concedere all'intero team una settimana libera in modo che possano eliminare la spazzatura. Quindi, in sostanza, dovrai trovare un modo per eliminare parzialmente queste classi, una alla volta. La parte più importante di questo è decidere - con tutto il team - cosa Employeesia veramente. Do Non di integrare tutti i singoli attributi in un dio-dipendente. Pensa più a un dipendente principale e, soprattutto, decidi dove Employeerisiederà quella classe.
Se si eseguono revisioni del codice, è particolarmente facile assicurarsi che il problema non si sviluppi ulteriormente, vale a dire fermare tutti nel loro percorso quando vogliono aggiungerne un altro Employee. Inoltre, assicurarsi che i nuovi sottosistemi aderiscano a quelli concordati Employeee non possano accedere alle versioni precedenti.
A seconda del linguaggio di programmazione, potresti anche voler contrassegnare le classi che verranno eventualmente eliminate con qualcosa di simile @Deprecatedper aiutare il tuo team a rendersi immediatamente conto che stanno lavorando con qualcosa che dovrà essere cambiato.
Per quanto riguarda l'eliminazione delle classi di dipendenti obsolete, puoi decidere per ogni singolo caso come è meglio eliminarlo o semplicemente concordare un modello comune. Puoi apporre il nome della classe e avvolgerlo attorno al vero impiegato, puoi usare i motivi (mi viene in mente decoratore o adattatore), oppure oppure oppure oppure.
Per farla breve: questa "pratica" è tecnicamente valida, ma è piena di costi nascosti che si verificano solo più avanti. Anche se potresti non essere in grado di eliminare immediatamente il problema, puoi iniziare immediatamente con il contenimento dei suoi effetti dannosi.