Come evitare di violare l'SRP in una classe per gestire la memorizzazione nella cache?

Nota: l'esempio di codice è scritto in c #, ma non dovrebbe importare. Ho messo c # come tag perché non riesco a trovarne uno più appropriato. Riguarda la struttura del codice.

Sto leggendo Clean Code e sto cercando di diventare un programmatore migliore.

Mi trovo spesso a lottare per seguire il principio della responsabilità singola (le classi e le funzioni dovrebbero fare solo una cosa), specialmente nelle funzioni. Forse il mio problema è che "una cosa" non è ben definita, ma comunque ...

Un esempio: ho un elenco di Fluffies in un database. Non ci interessa cosa sia Fluffy. Voglio una classe per recuperare le lanugine. Tuttavia, le lanugine possono cambiare secondo una certa logica. A seconda della logica, questa classe restituirà i dati dalla cache o otterrà le ultime dal database. Potremmo dire che gestisce le lanugine, e questa è una cosa. Per semplificare, supponiamo che i dati caricati siano validi per un'ora e quindi debbano essere ricaricati.

class FluffiesManager
{
    private Fluffies m_Cache;
    private DateTime m_NextReload = DateTime.MinValue;
    // ...
    public Fluffies GetFluffies()
    {
        if (NeedsReload())
            LoadFluffies();

        return m_Cache;
    }

    private NeedsReload()
    {
        return (m_NextReload < DateTime.Now);
    }

    private void LoadFluffies()
    {
        GetFluffiesFromDb();
        UpdateNextLoad();
    }

    private void UpdateNextLoad()
    {
        m_NextReload = DatTime.Now + TimeSpan.FromHours(1);
    }
    // ...
}

GetFluffies()mi sembra ok. L'utente chiede alcuni soffici, li forniamo. Andare a recuperarli dal DB se necessario, ma questo potrebbe essere considerato una parte dell'ottenere le lanugine (ovviamente, è un po 'soggettivo).

NeedsReload()sembra giusto. Verifica se dobbiamo ricaricare le lanugine. UpdateNextLoad va bene. Aggiorna il tempo per la prossima ricarica. questa è sicuramente una cosa sola.

Tuttavia, sento che cosa LoadFluffies()non può essere descritto come una sola cosa. Sta ottenendo i dati dal database e sta pianificando il prossimo ricaricamento. È difficile sostenere che il calcolo del tempo per la prossima ricarica faccia parte del recupero dei dati. Tuttavia, non riesco a trovare un modo migliore per farlo (rinominare la funzione LoadFluffiesAndScheduleNextLoadpotrebbe essere migliore, ma rende il problema più ovvio).

Esiste una soluzione elegante per scrivere davvero questa classe secondo l'SRP? Sono troppo pedante?

O forse la mia classe non sta davvero facendo solo una cosa?

Se questa classe fosse davvero banale come sembra, non sarebbe necessario preoccuparsi di violare l'SRP. Quindi cosa succede se una funzione a 3 linee ha 2 linee che fanno una cosa e un'altra 1 linea che fa un'altra cosa? Sì, questa banale funzione viola l'SRP, e allora? Che importa? La violazione dell'SRP inizia a diventare un problema quando le cose si complicano.

Il tuo problema in questo caso particolare deriva molto probabilmente dal fatto che la classe è più complicata delle poche righe che ci hai mostrato.

In particolare, il problema molto probabilmente risiede nel fatto che questa classe non solo gestisce la cache, ma probabilmente contiene anche l'implementazione del GetFluffiesFromDb()metodo. Quindi, la violazione dell'SRP è nella classe, non nei pochi metodi banali mostrati nel codice che hai pubblicato.

Quindi, ecco un suggerimento su come gestire tutti i tipi di casi che rientrano in questa categoria generale, con l'aiuto del modello Decoratore .

/// Provides Fluffies.
interface FluffiesProvider
{
    Fluffies GetFluffies();
}

/// Implements FluffiesProvider using a database.
class DatabaseFluffiesProvider : FluffiesProvider
{
    public override Fluffies GetFluffies()
    {
        ... load fluffies from DB ...
        (the entire implementation of "GetFluffiesFromDb()" goes here.)
    }
}

/// Decorates FluffiesProvider to add caching.
class CachingFluffiesProvider : FluffiesProvider
{
    private FluffiesProvider decoree;
    private DateTime m_NextReload = DateTime.MinValue;
    private Fluffies m_Cache;

    public CachingFluffiesProvider( FluffiesProvider decoree )
    {
        Assert( decoree != null );
        this.decoree = decoree;
    }

    public override Fluffies GetFluffies()
    {
        if( DateTime.Now >= m_NextReload ) 
        {
             m_Cache = decoree.GetFluffies();
             m_NextReload = DatTime.Now + TimeSpan.FromHours(1);
        }
        return m_Cache;
    }
}

ed è usato come segue:

FluffiesProvider provider = new DatabaseFluffiesProvider();
provider = new CachingFluffiesProvider( provider );
...go ahead and use provider...

Nota come CachingFluffiesProvider.GetFluffies()non ha paura di contenere il codice che fa il controllo e l'aggiornamento del tempo, perché è roba banale. Ciò che fa questo meccanismo è indirizzare e gestire l'SRP a livello di progettazione del sistema, dove è importante, non a livello di piccoli metodi individuali, dove comunque non importa.

La tua stessa classe mi sembra a posto, ma hai ragione LoadFluffies(), non esattamente quello che pubblicizza il nome. Una soluzione semplice sarebbe quella di cambiare il nome e spostare il ricaricamento esplicito da GetFluffies, in una funzione con una descrizione appropriata. Qualcosa di simile a

public Fluffies GetFluffies()
{
  MakeSureTheFluffyCacheIsUpToDate();
  return m_Cache;
}

private void MakeSureTheFluffyCacheIsUpToDate()
{
  if( !NeedsReload )
    return;
  GetFluffiesFromDb();
  SetNextReloadTime();
}

mi sembra pulito (anche perché come dice Patrick: è composto da altre minuscole funzioni obbedienti alla SRP), e soprattutto anche chiaro che a volte è altrettanto importante.

Credo che la tua classe stia facendo una cosa; è una cache di dati con un timeout. LoadFluffies sembra un'astrazione inutile a meno che non la chiami da più punti. Penso che sarebbe meglio prendere le due righe da LoadFluffies e metterle nel condizionale NeedsReload in GetFluffies. Ciò renderebbe molto più ovvia l'implementazione di GetFluffies ed è ancora un codice pulito, poiché stai componendo subroutine a responsabilità singola per raggiungere un unico obiettivo, un recupero cache dei dati dal db. Di seguito è riportato il metodo get fluffies aggiornato.

public Fluffies GetFluffies()
{
    if (NeedsReload()) {
        GetFluffiesFromDb();
        UpdateNextLoad();
    }

    return m_Cache;
}

Il tuo istinto è corretto. La tua classe, per quanto piccola, sta facendo troppo. È necessario separare la logica della cache di aggiornamento temporizzato in una classe completamente generica. Quindi crea un'istanza specifica di quella classe per la gestione di Fluffies, qualcosa del genere (non compilato, il codice di lavoro viene lasciato come esercizio per il lettore):

public class TimedRefreshCache<T> {
    T m_Value;
    DateTime m_NextLoadTime;
    Func<T> m_producer();
    public CacheManager(Func<T> T producer, Interval timeBetweenLoads) {
          m_nextLoadTime = INFINITE_PAST;
          m_producer = producer;
    }
    public T Value {
        get {
            if (m_NextLoadTime < DateTime.Now) {
                m_Value = m_Producer();
                m_NextLoadTime = ...;
            }
            return m_Value;
        }
    }
}

public class FluffyCache {
    private TimedRefreshCache m_Cache 
        = new TimedRefreshCache<Fluffy>(GetFluffiesFromDb, interval);
    private Fluffy GetFluffiesFromDb() { ... }
    public Fluffy Value { get { return m_Cache.Value; } }
}

Un ulteriore vantaggio è che ora è molto facile testare TimedRefreshCache.

La tua classe va bene, SRP riguarda una classe non una funzione, l'intera classe è responsabile di fornire i "Fluffies" dalla "Fonte dei dati", quindi sei libero nell'implementazione interna.

Se si desidera espandere il meccanismo di cahing, è possibile creare una classe responsabile per la visione dell'origine dati

public class ModelWatcher
{

    private static Dictionary<Type, DateTime> LastUpdate;

    public static bool IsUpToDate(Type entityType, DateTime lastRead) {
        if (LastUpdate.ContainsKey(entityType)) {
            return lastRead >= LastUpdate[entityType];
        }
        return true;
    }

    //call this method whenever insert/update changed to any entity
    private void OnDataSourceChanged(Type changedEntityType) {
        //update Date & Time
        LastUpdate[changedEntityType] = DateTime.Now;
    }
}
public class FluffyManager
{
    private DateTime LastRead = DateTime.MinValue;

    private List<Fluffy> list;



    public List<Fluffy> GetFluffies() {

        //if first read or not uptodated
        if (list==null || !ModelWatcher.IsUpToDate(typeof(Fluffy),LastRead)) {
            list = ReadFluffies();
        }
        return list;
    }
    private List<Fluffy> ReadFluffies() { 
    //read code
    }
}