La registrazione accanto a un'implementazione è una violazione di SRP?

Quando penso allo sviluppo di software agile e a tutti i principi (SRP, OCP, ...), mi chiedo come trattare la registrazione.

La registrazione accanto a un'implementazione è una violazione di SRP?

Direi che yesl'implementazione dovrebbe essere in grado di funzionare anche senza registrazione. Quindi, come posso implementare la registrazione in modo migliore? Ho controllato alcuni schemi e sono giunto alla conclusione che il modo migliore per non violare i principi in un modo definito dall'utente, ma per usare qualsiasi modello che è noto per violare un principio è quello di utilizzare un motivo decoratore.

Diciamo che abbiamo un sacco di componenti completamente senza violazione di SRP e quindi vogliamo aggiungere la registrazione.

• componente A
• il componente B utilizza A

Vogliamo registrare per A, quindi creiamo un altro componente D decorato con A implementando entrambi un'interfaccia I.

• interfaccia I.
• componente L (componente di registrazione del sistema)
• il componente A implementa I
• il componente D implementa I, decora / usa A, usa L per la registrazione
• il componente B utilizza un I

Vantaggi: - Posso usare A senza registrazione - Test A significa che non ho bisogno di alcuna beffa di registrazione - I test sono più semplici

Svantaggio: - più componenti e più test

So che questa sembra essere un'altra domanda di discussione aperta, ma in realtà voglio sapere se qualcuno utilizza strategie di registrazione migliori rispetto a un decoratore o una violazione di SRP. Che dire del logger singleton statico che è NullLogger predefinito e se si desidera la registrazione syslog, si cambia l'oggetto di implementazione in fase di esecuzione?

Sì, è una violazione di SRP in quanto la registrazione è una preoccupazione trasversale.

Il modo corretto è quello di delegare la registrazione a una classe logger (Intercettazione) il cui unico scopo è quello di effettuare la registrazione - rispettando l'SRP.

Vedi questo link per un buon esempio: https://msdn.microsoft.com/en-us/library/dn178467%28v=pandp.30%29.aspx

Ecco un breve esempio :

public interface ITenantStore
{
    Tenant GetTenant(string tenant);
    void SaveTenant(Tenant tenant);
}

public class TenantStore : ITenantStore
{
    public Tenant GetTenant(string tenant)
    {....}

    public void SaveTenant(Tenant tenant)
    {....}
} 

public class TenantStoreLogger : ITenantStore
{
    private readonly ILogger _logger; //dep inj
    private readonly ITenantStore _tenantStore;

    public TenantStoreLogger(ITenantStore tenantStore)
    {
        _tenantStore = tenantStore;
    }

    public Tenant GetTenant(string tenant)
    {
        _logger.Log("reading tenant " + tenant.id);
        return _tenantStore.GetTenant(tenant);
    }

    public void SaveTenant(Tenant tenant)
    {
        _tenantStore.SaveTenant(tenant);
        _logger.Log("saving tenant " + tenant.id);
    }
}

I vantaggi includono

• Puoi testarlo senza registrarti: test dell'unità reale
• puoi facilmente attivare / disattivare la registrazione, anche in fase di esecuzione
• è possibile sostituire la registrazione con altre forme di registrazione, senza dover modificare il file TenantStore.

Direi che stai prendendo SRP troppo sul serio. Se il tuo codice è abbastanza ordinato che la registrazione è l'unica "violazione" di SRP, allora stai facendo meglio del 99% di tutti gli altri programmatori e dovresti dare una pacca sulla spalla.

Lo scopo di SRP è di evitare il codice spaghetti orribile in cui il codice che fa cose diverse è tutto confuso. Mischiare la registrazione con il codice funzionale non suona alcun campanello d'allarme per me.

No, non è una violazione di SRP.

I messaggi inviati al registro dovrebbero cambiare per gli stessi motivi del codice circostante.

Ciò che è una violazione di SRP è l'utilizzo di una libreria specifica per accedere direttamente al codice. Se si decide di modificare il modo di registrazione, SRP afferma che non dovrebbe influire sul codice aziendale.

Una sorta di abstract Loggerdovrebbe essere accessibile al codice di implementazione e l'unica cosa che l'implementazione dovrebbe dire è "Invia questo messaggio al registro", senza preoccuparsi del modo in cui è stato fatto. Decidere il modo esatto di registrazione (anche il timestamp) non è responsabilità dell'implementazione.

L'implementazione quindi non dovrebbe inoltre sapere se il logger a cui sta inviando messaggi è a NullLogger.

Detto ciò.

Non spazzerei via la registrazione perché una preoccupazione trasversale è troppo veloce . L'emissione dei registri per tracciare eventi specifici che si verificano nel codice di implementazione appartiene al codice di implementazione.

Ciò che è una preoccupazione trasversale, OTOH, è la traccia dell'esecuzione : la registrazione entra ed esce in ogni metodo. AOP è nella posizione migliore per farlo.

Poiché la registrazione è spesso considerata una preoccupazione trasversale, suggerirei di utilizzare AOP per separare la registrazione dall'implementazione.

A seconda della lingua che utilizzeresti per utilizzare un intercettore o un framework AOP (ad es. AspectJ in Java).

La domanda è se questo vale davvero la seccatura. Nota che questa separazione aumenterà la complessità del tuo progetto fornendo al contempo pochissimi benefici.

Questo suona bene. Stai descrivendo un decoratore di registrazione abbastanza standard. Hai:

componente L (componente di registrazione del sistema)

Ciò ha una responsabilità: la registrazione delle informazioni che gli vengono passate.

il componente A implementa I

Ciò ha una responsabilità: fornire un'implementazione dell'interfaccia I (supponendo che sia correttamente conforme a SRP, cioè).

Questa è la parte cruciale:

il componente D implementa I, decora / usa A, usa L per la registrazione

Se detto in questo modo, sembra complesso, ma guardalo in questo modo: il componente D fa una cosa: riunire A e L.

• Il componente D non registra; lo delega a L
• Il componente D non implementa I stesso; lo delega ad A

L' unica responsabilità che ha il componente D è assicurarsi che L sia avvisato quando si usa A. Le implementazioni di A e L sono entrambe altrove. Questo è completamente conforme a SRP, oltre ad essere un chiaro esempio di OCP e un uso piuttosto comune dei decoratori.

Un avvertimento importante: quando D usa il componente di registrazione L, dovrebbe farlo in un modo che ti consenta di cambiare il modo in cui stai registrando. Il modo più semplice per farlo è avere un'interfaccia IL implementata da L. Quindi:

• Il componente D utilizza un IL per accedere; viene fornita un'istanza di L.
• Il componente D utilizza un I per fornire funzionalità; viene fornita un'istanza di A.
• Il componente B utilizza una I; viene fornita un'istanza di D.

In questo modo, nulla dipende direttamente da qualsiasi altra cosa, facilitando la sostituzione. Ciò consente di adattarsi facilmente ai cambiamenti e di prendere in giro parti del sistema in modo da poter eseguire il test dell'unità.

Ovviamente si tratta di una violazione dell'SRP poiché hai una preoccupazione trasversale. Tuttavia, è possibile creare una classe responsabile della composizione della registrazione con l'esecuzione di qualsiasi azione.

esempio:

class Logger {
   ActuallLogger logger;
   public Action ComposeLog(string msg, Action action) {
      return () => {
          logger.debug(msg);
          action();
      };
   }
}