La capacità di individuare dove viene utilizzato il codice deve essere considerata?

4

Stavo modificando una classe il cui compito è caricare altre classi dalla stessa directory. In sostanza, ogni volta che viene aggiunta una nuova classe, è necessario aggiungere un'istruzione new CommandClass; a questa classe per caricarla.

Ho pensato che fosse strano e violasse il principio "Chiuso per la modifica", quindi invece di aggiungere un'altra linea a 70 esistenti, l'ho cambiato per caricare automaticamente tutte queste classi.

Dopo un po 'due persone hanno sostenuto che con l'autoloading di quelle classi, non sono in grado di trovare dove vengono utilizzate queste classi, cioè non possono grep per i nomi delle classi per individuare i file che li stanno utilizzando.

Considerando che altri lo hanno già fatto per più di settanta volte, ho ripristinato il mio cambiamento (e ne ho aggiunto un altro). Tuttavia, non sono ancora sicuro, questo argomento ha un peso reale? Quale modo migliore è lì per soddisfare il loro bisogno di localizzare il codice?

    
posta imel96 24.06.2016 - 09:32
fonte

1 risposta

9

In generale, ogni volta che usi tecniche di caricamento dinamico o di accesso, dovrai affrontare il problema che i tuoi tipici strumenti di ricerca, refactoring o riferimenti incrociati non possono facilmente determinare quale codice viene usato dove, cosa refactoring o da dove viene chiamato un pezzo di codice.

Quindi, ogni volta che consideri di utilizzare una tale tecnica, tieni presente che si tratta di un compromesso - dal punto di vista professionale, il tuo codice diventa più SECCO, o sarà conforme all'OCP e così diventa più facilmente estendibile. Quest'ultimo è particolarmente utile quando si crea una libreria o un framework in cui l'utente di tale libreria non è in grado di modificare o estendere arbitrariamente il codice sorgente lib. Dal lato positivo, l'intero meccanismo diventa meno ovvio. Se si utilizzano queste tecniche troppo spesso, esiste un certo rischio che il codice possa diventare difficile da comprendere o complicato. Pertanto, dovrai prendere una decisione su una base per ogni caso, il cui approccio ti servirà meglio in totale.

Nel tuo caso specifico, sembra che ci potrebbe essere un po 'di superstizione dei tuoi colleghi coinvolti - hanno davvero bisogno di trovare la parte del codice che contiene la classe "load" usando grep e cerca una classe specifica nome? Se, ad esempio, cambierà un nome delle classi, il caricatore automatico non dovrà essere modificato, quindi non c'è bisogno di comprarlo. E 70 ripetizioni di codice simile sono sicuramente un odore di codice - quando in futuro avrai un requisito che causa lo stesso tipo di modifica a ciascuna di quelle 70 linee, allora un autoloader mostrerà il suo valore reale.

D'altra parte, cambiare il caricatore ogni volta che viene aggiunta una nuova classe non sembra essere un grosso problema nella tua situazione attuale, perché hai il pieno controllo del codice sorgente, e si spera che non si ripeta molto codice . Immagino che quando devi aggiungere una classe, non si possa facilmente dimenticare di estendere il caricatore (il tuo sistema probabilmente non sarebbe in grado di eseguire il codice della nuova classe). E quando uno dei tuoi team vuole mantenere alcune vecchie versioni delle classi nella directory, ma non vuole che vengano caricate (ad esempio, a scopo di test), una "lista bianca" di classi da caricare può avere alcuni vantaggi, anche.

Alla fine, devi considerare queste due parti e prendere una decisione per il tuo caso.

    
risposta data 24.06.2016 - 13:08
fonte

Leggi altre domande sui tag