quale dovrebbe essere la posizione del logger nell'elenco dei parametri [chiuso]

Nel mio codice inserisco un logger in molte delle mie classi attraverso l'elenco dei parametri del loro costruttore

Ho notato che l'ho messo a caso: a volte è il primo della lista, a volte l'ultimo, a volte in mezzo

Hai qualche preferenza? La mia intuizione dice che la coerenza è utile in questo caso e la mia preferenza personale è quella di metterla al primo posto in modo che sia più facile essere notato quando manca e più facile saltare quando è lì.

I logger sono ciò che chiamiamo "preoccupazione trasversale". Si arrendono a tecniche come la programmazione orientata agli aspetti; se hai un modo per decorare le tue classi con un attributo o eseguire un po 'di intreccio di codice, questo è un buon modo per ottenere capacità di registrazione mantenendo "puri" i tuoi oggetti e gli elenchi di parametri.

L'unico motivo per cui potresti voler passare in un logger è se vuoi specificare diverse implementazioni di logging, ma la maggior parte dei framework di logging ha la flessibilità di permetterti di configurarli, diciamo, per differenti target di logging. (file di registro, Gestione eventi di Windows, ecc.)

Per questi motivi, preferisco rendere la registrazione una parte naturale del sistema, piuttosto che passare un logger in ogni classe per scopi di registrazione. Quindi, ciò che faccio generalmente è fare riferimento allo spazio dei nomi di registrazione appropriato e utilizzare semplicemente il logger nelle mie classi.

Se vuoi ancora passare un logger, la mia preferenza è che tu lo renda l' ultimo parametro nell'elenco dei parametri (rendilo un parametro opzionale, se possibile). Avere il primo parametro non ha molto senso; il primo parametro dovrebbe essere il più importante, quello più rilevante per il funzionamento della classe.

Nelle lingue con sovraccarico di funzioni, direi che più è probabile che un argomento sia facoltativo, più dovrebbe essere giusto. Ciò crea coerenza quando si creano sovraccarichi in cui mancano:

foo(mandatory);
foo(mandatory, optional);
foo(mandatory, optional, evenMoreOptional);

Nei linguaggi funzionali è più utile il contrario: più è probabile che tu scelga alcuni valori predefiniti, più dovrebbe rimanere. Ciò semplifica la specializzazione della funzione semplicemente applicando argomenti ad essa:

addThreeToList = map (+3)

Tuttavia, come indicato nelle altre risposte, probabilmente non si desidera passare esplicitamente il logger nell'elenco degli argomenti di ogni classe nel sistema.

Puoi sicuramente dedicare molto tempo a progettare eccessivamente questo problema.

Per le lingue con implementazioni di registrazione canonica, basta creare un'istanza del registratore canonico direttamente in ogni classe.

Per le lingue senza un'implementazione canonica, prova a trovare un framework di facciata di registrazione e attenersi ad esso. slf4j è una buona scelta in Java.

Personalmente preferirei attenermi a un'unica implementazione di registrazione concreta e inviare tutto a syslog. Tutti i buoni strumenti di analisi dei log sono in grado di combinare i log di sysout da più server di app in un report completo.

Quando una firma di funzione include uno o due servizi di dipendenza e alcuni argomenti "reali", inserisco le dipendenze per ultime:

int calculateFooBarSum(int foo, int bar, IntegerSummationService svc)

Poiché i miei sistemi tendono ad avere solo cinque o meno di tali servizi, mi assicuro sempre che i servizi siano inclusi nello stesso ordine in tutte le firme delle funzioni. L'ordine alfabetico è buono come un altro. (A parte: mantenere questo approccio metodologico per la gestione del mutex ridurrà anche le tue possibilità di sviluppare deadlock.)

Se ti ritrovi a iniettare più di una dozzina di dipendenze nella tua app, probabilmente il sistema deve essere suddiviso in sottosistemi separati (oserei dire microservizi?).

I logger sono un po 'un caso speciale perché devono essere disponibili letteralmente ovunque.

Se hai deciso di voler passare un logger nel costruttore di ogni classe, allora dovresti sicuramente impostare una convenzione coerente per il modo in cui lo fai (ad esempio, sempre il primo parametro, sempre passato per riferimento, l'elenco di inizializzazione del costruttore inizia sempre con m_logger (theLogger), ecc.). Qualunque cosa che verrà utilizzata nell'intera base di codice un giorno trarrà beneficio dalla coerenza.

In alternativa, è possibile che ogni classe crei un'istanza del proprio oggetto logger, senza che sia necessario alcun passaggio. Il logger potrebbe aver bisogno di sapere alcune cose "per magia" affinché funzioni, ma codificare un percorso file nella definizione della classe è potenzialmente un molto più gestibile e meno noioso che trasmetterlo correttamente a centinaia di classi diverse, e probabilmente molto meno malvagio che usare una variabile globale per bypassare detto tedio. (Certo, i logger sono tra i pochissimi casi d'uso legittimi per le variabili globali)

Sono d'accordo con quelli che suggeriscono che il logger dovrebbe essere accessibile staticamente piuttosto che passare alle classi. Tuttavia, se c'è una ragione forte per cui vuoi passarlo (forse istanze diverse vogliono accedere a posizioni diverse o qualcosa del genere) allora suggerirei di non passarlo usando il costruttore ma piuttosto di effettuare una chiamata separata per farlo, ad es. Class* C = new C(); C->SetLogger(logger);Piuttosto diClass* C = new C(logger);

Il motivo per preferire questo metodo è che il logger non è essenzialmente una parte della classe ma piuttosto una funzione iniettata utilizzata per qualche altro scopo. Inserirlo nell'elenco dei costruttori lo rende un requisito della classe e implica che fa parte dello stato logico effettivo della classe. E 'ragionevole aspettarsi, per esempio (con la maggior parte le classi anche se non tutti), che se X != Yallora C(X) != C(Y), ma è improbabile che si sarebbe testare logger disuguaglianza se si confrontano anche istanze della stessa classe.

Vale la pena menzionare, qualcosa che non ho visto toccare le altre risposte qui, è che rendendo il logger iniettato tramite proprietà o statico, rende difficile (er) testare la classe. Ad esempio, se si effettua l'iniezione del logger tramite la proprietà, sarà necessario iniettare tale logger ogni volta che si verifica un metodo che utilizza il logger. Questo significa che potresti anche averlo impostato come dipendenza del costruttore perché la classe lo richiede.

Statico si presta allo stesso problema; se il logger non funziona, allora l'intera classe fallisce (se la tua classe usa il logger) - anche se il logger non fa necessariamente parte della responsabilità della classe - anche se non è così male come l'iniezione di proprietà perché tu almeno sapere che il logger è sempre "lì" in un certo senso.

Solo un po 'di spunti di riflessione, soprattutto se impieghi TDD. A mio avviso, un logger non dovrebbe davvero far parte di una parte testabile di una classe (quando si verifica la classe, non si dovrebbe testare anche la registrazione).

Sono troppo pigro per passare un oggetto logger a ogni istanza della classe. Quindi, nel mio codice, questo genere di cose si trova in un campo statico o in una variabile thread-local in un campo statico. Quest'ultimo è piuttosto interessante e ti consente di utilizzare un logger diverso per ogni thread e ti consente di aggiungere metodi per accendere e spegnere la registrazione che fanno qualcosa di significativo e atteso in un'applicazione multi-thread.