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.