Expiration de l'instance Singleton après une période de temps

Question

Mise de côté, pour l'instant, des arguments concernant les vertus et disvirtues relatives du motif Singleton, et considérant qu'un Singleton est généralement considéré comme une instance qui persiste pendant la durée de vie d'une application, Quelle serait la meilleure façon d'avoir un Singleton qui a une vie limitée?

Y at-il quelque chose de mal avec quelque chose comme ce qui suit:

public class CategoryHandler 
{  

    private static DateTime m_expires; 

    public bool HasExpired 
    { 
     get return DateTime.Now > m_expires; 
    } 

    private CategoryHandler() 
    { 
     m_expires = DateTime.Now.AddMinutes(60); 
    } 

    public static CategoryHandler Instance() 
    { 
     if(HasExpired) 
     { 
      //Dispose and reconstruct 
     } 
     else 
     { 
      //Use existing instance 
     } 
    } 

} 

Ou est-il un moyen beaucoup mieux d'aborder ce problème?

Answer 1

Vous aurez besoin d'une sorte de verrouillage pour assurer la sécurité des threads:

public sealed class CategoryHandler 
{ 
    private static CategoryHandler _instance = null; 
    private static DateTime _expiry = DateTime.MinValue; 
    private static readonly object _lock = new object(); 

    private CategoryHandler() { } 

    public static bool HasExpired 
    { 
     get 
     { 
      lock (_lock) { return (_expiry < DateTime.Now); } 
     } 
    } 

    public static CategoryHandler Instance 
    { 
     get 
     { 
      lock (_lock) 
      { 
       if (HasExpired) 
       { 
        // dispose and reconstruct _instance 
        _expiry = DateTime.Now.AddMinutes(60); 
       } 
       return _instance; 
      } 
     } 
    } 
} 

Answer 2

Le seul problème majeur que je peux voir est qu'une autre classe a déjà une référence à l'ancienne instance, cela ne l'invalidera pas. Donc, tant que toutes les classes font:

CategoryHandler.Instance.Method(); 

plutôt que

CategoryHandler singleton = CategoryHandler.Instance; 
... 
singleton.SomeMethod(); 

vous devriez bien à condition que vous êtes heureux que le singleton prendra fin la prochaine fois qu'il est fait référence plutôt que après exactement soixante minutes .

Si vous avez besoin qu'il expire après une période de temps précise, alors vous devrez utiliser une minuterie et remplacer l'instance dans la méthode de rappel (attention le minuteur rappellera dans un thread différent alors assurez-vous d'implémenter un modèle de singleton sûr de filetage)

Answer 3

Que voulez-vous exactement accomplir avec un singleton expirant? Je pense que vous avez un problème avec votre conception si vous voulez vraiment faire cela. Et comme Martin l'a dit, vous aurez des ennuis si du code "capture" votre instance singleton.

Alors, quelle est exactement votre utilisation pour cela? Ou est la question juste par curiosité?

Answer 4

Pour éviter d'avoir le problème avec des classes ayant des références à une ancienne instance que vous pourriez envisager d'écrire un wrapper de mise en cache pour votre classe. extrait du poing le ICategoryHandler d'interface, permet de supposer qu'il ressemble à ceci:

interface ICategoryHandler 
{ 
    int A(); 
} 

et vous mettre en œuvre l'enveloppe (verrouillage omis):

class CategoryHandlerWrapper : ICategoryHandler 
{ 
    ICategoryHandler instance; 
    private DateTime expiry = DateTime.MinValue; 

    public int A() 
    { 
    return Instance().A(); 
    } 

    public bool HasExpired 
    { 
     get return DateTime.Now > expiry; 
    } 

    private CategoryHandler Instance() 
    { 
     if(HasExpired) 
     { 
      //Dispose and reconstruct 
     } 
     else 
     { 
      //Use existing instance 
     } 
    } 
} 

De cette façon, vous pouvez utiliser l'injection de dépendance normale et toujours profiter de la caractéristique que vous êtes après. Aussi le problème avec les anciennes références est encapsulé dans un endroit.

Answer 5

Avez-vous envisagé d'utiliser un IoC/DI Container framework et de gérer la durée de vie du "singleton"?

La version Unity de Microsoft est celle que je connais le mieux, et elle ne fournit pas un LifetimeManager prêt à l'emploi qui fasse exactement ce que vous voulez faire. Cependant, vous pouvez créer votre propre descendant; voir Writing Custom Lifetime Managers.

Ou vous pouvez regarder les autres cadres et voir si l'on a ce que vous voulez dans la boîte.

EDIT: Notez que cela ne vous sortira pas du problème "capturé" mentionné par Martin.