Aggiunta di un meccanismo di registrazione centralizzato al progetto (best practice)

2

Voglio aggiungere un meccanismo di registrazione al mio progetto, ma temo che il codice di registrazione venga diffuso ovunque.

Ho quindi avuto l'idea di avere solo una classe Logger responsabile della scrittura di informazioni rilevanti nel log e tutte le altre classi A, B, ... avendo un oggetto Logger e semplicemente chiamando la corrispondente funzione di registrazione in quella Classe Logger invece di implementare la funzione di registrazione nelle classi A, B, direttamente.

class A {
  public:
    Logger logger;
    ...
    void foo {
       ...
       logger.log(this);
    }
};

...

class Logger {
  public:
    void log(A a);
    void log(B b);
...

};

È considerata una buona pratica o un modo pulito di fare il logging senza ingombrare il codice di produzione?

    
posta 1v0 10.08.2015 - 04:45
fonte

2 risposte

3

Vorrei strongmente raccomandare contro questo design. Stai creando una dipendenza ciclica tra le singole classi del tuo progetto A, B, C, ... e la tua classe Logger, che rende il tuo Logger inutilizzabile in altri progetti o in componenti del tuo progetto che non dipendono da A, B e C. Inoltre, ogni volta che aggiungerai una nuova classe che richiede la registrazione, non dovrai solo azzardare quella classe, ma anche il Logger. E se vuoi mettere il Logger in una libreria separata, riutilizzabile, ottieni una dipendenza ciclica tra quella lib e la libreria dove A, B, C vivono (per fortuna, in linguaggi come C # quest'ultimo è vietato).

Questo è esattamente il modo per la ben nota "architettura della grande palla di fango" .

    
risposta data 31.10.2015 - 09:45
fonte
2

Vale la pena dedicare il tempo necessario per imparare la libreria log4 *, ad es. per ragioni come registrazione gerarchica, filtri, diversi formati di output o destinazioni (file, database, programmi di messaggistica istantanea, ...).

Ma non rimuoverà le dichiarazioni di logging dal tuo codice, solo un buon punto di partenza. Per ridurre al minimo il codice di registrazione, puoi provare Aspect Oriented Programming, che "intreccia" le istruzioni in funzioni che corrispondono a un modello specifico, o ...

Potresti sfruttare la tua architettura software: alcune architetture consentono il codice di registrazione nei punti sensibili centrali, ad es. dispatcher di messaggi o contenitori di iniezione di dipendenza, ecc. IMHO è una buona idea centralizzare la gestione delle eccezioni (usando un modello di "facciata di sicurezza"). Questo renderebbe un altro punto centrale per la registrazione degli errori.

Solo alcune opzioni.

    
risposta data 10.08.2015 - 23:48
fonte

Leggi altre domande sui tag