Comment éviter de violer le SRP dans une classe pour gérer la mise en cache?

Remarque: l' exemple de code est écrit en c #, mais cela n'a pas d'importance. J'ai mis c # comme balise parce que je ne peux pas en trouver de plus approprié. Il s'agit de la structure du code.

Je lis Clean Code et j'essaie de devenir un meilleur programmeur.

J'ai souvent du mal à suivre le principe de responsabilité unique (les classes et les fonctions ne devraient faire qu'une seule chose), spécialement dans les fonctions. Peut-être que mon problème est qu'une "chose" n'est pas bien définie, mais quand même ...

Un exemple: j'ai une liste de Fluffies dans une base de données. Peu nous importe ce qu'est un Fluffy. Je veux qu'un cours récupère les peluches. Cependant, les peluches peuvent changer selon une logique. Selon une logique, cette classe retournera les données du cache ou obtiendra la dernière de la base de données. On pourrait dire qu'il gère les peluches, et c'est une chose. Pour faire simple, disons que les données chargées sont bonnes pendant une heure, puis elles doivent être rechargées.

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()me semble bien. L'utilisateur demande des peluches, nous les lui fournissons. Aller les récupérer de la base de données si nécessaire, mais cela pourrait être considéré comme une partie de l'obtention des peluches (bien sûr, c'est quelque peu subjectif).

NeedsReload()semble bien aussi. Vérifie si nous devons recharger les peluches. UpdateNextLoad est très bien. Met à jour l'heure du prochain rechargement. c'est certainement une seule chose.

Cependant, je pense que LoadFluffies()ce qui ne peut pas être décrit comme une seule chose. Il récupère les données de la base de données et planifie le prochain rechargement. Il est difficile de prétendre que le calcul du temps pour le prochain rechargement fait partie de l'obtention des données. Cependant, je ne peux pas trouver une meilleure façon de le faire (renommer la fonction en LoadFluffiesAndScheduleNextLoadpeut être meilleur, mais cela rend le problème plus évident).

Existe-t-il une solution élégante pour vraiment écrire cette classe selon le SRP? Suis-je trop pédant?

Ou peut-être que ma classe ne fait pas vraiment une seule chose?

Si cette classe était vraiment aussi triviale qu'elle semble l'être, alors il n'y aurait pas besoin de s'inquiéter de violer le SRP. Que se passe-t-il si une fonction à 3 lignes a 2 lignes qui font une chose et une autre 1 ligne qui fait autre chose? Oui, cette fonction triviale viole le SRP, et alors quoi? On s'en fout? La violation du SRP commence à devenir un problème lorsque les choses se compliquent.

Votre problème dans ce cas particulier vient très probablement du fait que la classe est plus compliquée que les quelques lignes que vous nous avez montrées.

Plus précisément, le problème réside très probablement dans le fait que cette classe gère non seulement le cache, mais contient également probablement l'implémentation de la GetFluffiesFromDb()méthode. Ainsi, la violation du SRP est dans la classe, pas dans les quelques méthodes triviales qui sont affichées dans le code que vous avez publié.

Donc, voici une suggestion sur la façon de gérer toutes sortes de cas qui entrent dans cette catégorie générale, à l'aide du modèle de décorateur .

/// 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;
    }
}

et il est utilisé comme suit:

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

Notez comment CachingFluffiesProvider.GetFluffies()n'a pas peur de contenir le code qui effectue le temps de vérification et de mise à jour, car c'est une chose triviale. Ce que ce mécanisme fait, c'est d'aborder et de gérer le SRP au niveau de la conception du système, là où cela compte, pas au niveau de minuscules méthodes individuelles, où cela n'a pas d'importance de toute façon.

Votre classe me semble bien, mais vous avez raison, ce LoadFluffies()n'est pas exactement ce que le nom annonce. Une solution simple serait de changer le nom et de déplacer le rechargement explicite de GetFluffies, dans une fonction avec une description appropriée. Quelque chose comme

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

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

me semble propre (aussi parce que, comme le dit Patrick: il est composé d'autres minuscules fonctions obéissant à SRP), et surtout aussi clair, ce qui est parfois tout aussi important.

Je crois que votre classe fait une chose; c'est un cache de données avec un délai d'attente. LoadFluffies semble être une abstraction inutile à moins que vous ne l'appeliez de plusieurs endroits. Je pense qu'il serait préférable de prendre les deux lignes de LoadFluffies et de les mettre dans le conditionnel NeedsReload dans GetFluffies. Cela rendrait l'implémentation de GetFluffies beaucoup plus évidente et est toujours du code propre, car vous composez des sous-programmes à responsabilité unique pour atteindre un seul objectif, une récupération en cache des données de la base de données. Vous trouverez ci-dessous la méthode mise à jour de get fluffies.

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

    return m_Cache;
}

Vos instincts sont corrects. Votre classe, si petite soit-elle, en fait trop. Vous devez séparer la logique de mise en cache d'actualisation temporisée en une classe complètement générique. Ensuite, créez une instance spécifique de cette classe pour gérer Fluffies, quelque chose comme ça (non compilé, le code de travail est laissé comme exercice pour le lecteur):

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 avantage supplémentaire est qu'il est désormais très facile de tester TimedRefreshCache.

Votre classe va bien, SRP concerne une classe et non une fonction, toute la classe est responsable de fournir les "Fluffies" de la "Data Source" afin que vous soyez libre dans l'implémentation interne.

Si vous souhaitez étendre le mécanisme de cahing, vous pouvez créer une classe respnsible pour regarder la source de données

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
    }
}