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

Prendendo un esempio di una semplice applicazione Ruby on Rails. Crea un Loggeroggetto durante il processo di caricamento dell'applicazione:

# in environment.rb
config.logger = Logger.new(<STDOUT | file | whatever>)

# and in our application we use this object
logger.warn "This process is taking too long to process. Optimization needed."

La mia domanda è: perché non utilizziamo metodi di classe (o metodi statici) per la registrazione? Non Logger.warnridimensionare di Logger.new.warn? O almeno Logger.warnsembra intuitivo Logger.new.warn.

Anche se Logger.newè un oggetto singleton, quali vantaggi offre?

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 registrazione log4j si inizializzava da un file XML. Il file XML stesso potrebbe contenere più logger con diverse configurazioni (dove si scrive, a quali livelli sono scritti, ecc.). Quindi, in questo caso avresti oggetti logger piuttosto che metodi statici logger per specificare quale logger vuoi invocare. Vale a dire.

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

registrerebbe cose relative alla connettività di rete, pacchetti rilasciati, ecc. o

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

che registra le cose relative alla tua logica / applicazione aziendale. Almeno con log4j è anche possibile configurare quali livelli di registro vengono effettivamente scritti (informazioni, traccia, avviso, errore, debug essendo i livelli predefiniti disponibili).

Se avessi metodi statici, il meglio che potresti fare è configurare un singolo logger che indichi standard out, un file, ecc., Ma tutto ciò che registri andrebbe nello stesso posto. Con gli oggetti logger, è più facile 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 a quale livello accedere per non accedere affatto per parti del programma senza dover ricompilare il progetto.

In questo modo è possibile disabilitare tutti i log tranne quelli di alto livello (errori) per le build di rilascio e attivare solo il livello più basso per le parti di cui si sta eseguendo il debug.

L'invocazione del metodo statico dovrebbe essere evitata ove possibile. È un'alternativa antiquata alla corretta iniezione di dipendenza, e non qualcosa che troverai utile in una base di codice più ampia.

Considerare la testabilità, ad esempio. La registrazione staticamente invocata mette l'oggetto in prova in controllo di quale classe di registrazione viene utilizzata - non c'è inversione di controllo. Non c'è possibilità di iniettare un oggetto simulato o qualsiasi tipo di falso qui. Iniettando il logger nel SUT, scoprirai che hai la possibilità di deridere il logger e iniettarlo.

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

Nel complesso, ti suggerirei di provare un approccio DI, quindi non troverai il tuo codice non testabile e ingombrante in seguito.