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

Question

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

#1 da (16 voti)
#2 da (2 voti)
#3 da (2 voti)

12

Ecco un esempio di una semplice applicazione Ruby on Rails. Crea un oggetto Logger 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 usiamo metodi di classe (o metodi statici) per la registrazione? Non sarà Logger.warn scala di Logger.new.warn ? Oppure almeno Logger.warn sembra intuitivo rispetto a Logger.new.warn .

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

development-process logging

posta Harsh Gupta 30.06.2015 - 14:51

fonte

3 risposte

2

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.

risposta data 30.06.2015 - 15:01

fonte

2

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.

risposta data 27.07.2015 - 23:10

fonte

Leggi altre domande sui tag development-process logging

Invarianti di vita dell'oggetto vs. spostare semantica Questa affermazione dagli algoritmi fondamentali di Knuth è ancora applicabile oggi? [chiuso]

score 16 · Accepted Answer

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.