Perché creare un oggetto Logger invece di utilizzare metodi di registrazione statici su un'applicazione?

Ecco un esempio che utilizza Java. È passato un po 'di tempo da quando ho usato log4j, ma da quello che ricordo, l'intero strumento di log4j sarebbe stato inizializzato da un file XML. Il file XML stesso potrebbe contenere più logger con diverse configurazioni (dove scrivi, quali livelli sono scritti, ecc.). Quindi, in questo caso si avrebbero gli oggetti logger invece dei metodi statici del logger per specificare quale logger si desidera richiamare. Vale a dire.

Logger logger = Logger.get("Network");

registra le cose relative alla connettività di rete, ai pacchetti abbandonati, ecc. o

Logger logger = Logger.get("Application");

che registra le cose relative alla tua business logic / applicazione. Almeno con log4j puoi anche configurare quali livelli di log vengono effettivamente scritti (informazioni, traccia, avviso, errore, debug essendo i livelli predefiniti disponibili).

Se disponevi di metodi statici, il meglio che puoi fare è configurare un singolo logger che indichi lo standard standard, un file, ecc., ma tutto ciò che registri andrebbe nello stesso posto. Con gli oggetti logger, è più semplice farlo in modo che le informazioni di registrazione siano distribuite su più file.

Logger.new è una factory che prenderà dove verrà utilizzato il risultato (nome della classe / file).

Nei file di configurazione è quindi possibile decidere quale livello registrare per non registrare affatto per parti del programma senza dover ricompilare il progetto.

Così puoi disabilitare tutti gli errori (log) di alto livello per le build di rilascio e attivare solo il livello più basso per le parti che stai eseguendo il debug.

L'invocazione del metodo statico dovrebbe essere evitata ogni qualvolta possibile. È un'alternativa antiquata alla corretta Iniezione delle dipendenze, e non qualcosa che troverai utile in una base di codice più grande.

Considerare la testabilità, per esempio. Il richiamo statico del logging mette il Subject Under Test in controllo su quale classe di logging è usata - non c'è Inversion of Control. Non c'è possibilità di iniettare un oggetto finto o qualsiasi tipo di falso qui. Inserendo il logger nel SUT, scoprirai che hai la possibilità di prendere in giro il logger e iniettarlo.

I vantaggi dell'uso di DI rispetto al tipo di invocazione del metodo statico in discussione vanno oltre la testabilità, naturalmente. Considera cosa succederebbe se volessi avere due diversi logger nel tuo sistema e l'opzione per cambiare il comportamento dell'applicazione attraverso la configurazione del solo grafico dell'oggetto, senza modificare il codice esistente.

In generale, ti suggerisco di provare un approccio DI, in modo da non trovare il tuo codice non verificabile e poco maneggevole in seguito.