C# abstraite méthode Dispose

Question

J'ai une classe abstraite qui implémente IDisposable, comme ceci:

public abstract class ConnectionAccessor : IDisposable 
{ 
    public abstract void Dispose(); 
} 

Dans Visual Studio 2008 Team System, j'ai couru l'analyse du code sur mon projet et l'une des mises en garde qui est venu était le suivant:

Microsoft.Design: Modifier 'ConnectionAccessor.Dispose() de sorte qu'il appelle Dispose (vrai), puis appelle GC.SuppressFinalize sur l'instance actuelle de l'objet ('ceci' ou 'moi' dans Visual Basic), puis revient.

Est-il juste être stupide, me disant de modifier le corps d'une méthode abstraite, ou devrais-je faire quelque chose de plus dans une instance dérivée de Dispose?

Answer 1

Vous devez suivre le schéma classique pour la mise en œuvre Dispose. Rendre Dispose() virtuel est considéré comme une mauvaise pratique, car le modèle conventionnel met l'accent sur la réutilisation du code dans le "nettoyage géré" (appel client Dispose() directement ou via using) et "nettoyage non géré" (GC appel finalizer). Pour rappel, le modèle est le suivant:

public class Base 
{ 
    ~Base() 
    { 
     Dispose(false); 
    } 

    public void Dispose() 
    { 
     Dispose(true); 
     GC.SuppressFinalize(this); // so that Dispose(false) isn't called later 
    } 

    protected virtual void Dispose(bool disposing) 
    { 
     if (disposing) 
     { 
      // Dispose all owned managed objects 
     } 

     // Release unmanaged resources 
    } 
} 

clé ici est qu'il n'y a pas de double emploi entre finaliseur et Dispose pour le nettoyage non géré, mais une classe dérivée peut étendre à la fois le nettoyage géré et non géré.

Pour votre cas, ce que vous devez faire est la suivante:

protected abstract void Dispose(bool disposing) 

et laisser tout le reste est. Même cela est d'une valeur douteuse, puisque vous appliquez vos classes dérivées pour implémenter Dispose maintenant - et comment savez-vous que tous en ont besoin? Si votre classe de base n'a rien à éliminer, mais que la plupart des classes dérivées le font (à quelques exceptions près, peut-être), fournissez simplement une implémentation vide. C'est ce que fait System.IO.Stream (lui-même abstrait), donc il y a un précédent.

Answer 2

L'avertissement vous indique fondamentalement d'implémenter le Dispose pattern dans votre classe.

Le code résultant devrait ressembler à ceci:

public abstract class ConnectionAccessor : IDisposable 
{ 
    ~ConnectionAccessor() 
    { 
     Dispose(false); 
    } 

    public void Dispose() 
    { 
     Dispose(true); 
     GC.SuppressFinalize(this); 
    } 

    protected virtual void Dispose(bool disposing) 
    { 
    } 
} 

Answer 3

L'avertissement est intéressant cependant. Eric Lippert, l'un des concepteurs de C#, a écrit un blog sur la raison pour laquelle les messages d'erreur devraient être «Diagnostique mais pas prescriptif: décrivez le problème, pas la solution». Read here.

Answer 4

Bien que cela ressemble un peu à du nit-picking, le conseil est valable. Vous indiquez déjà que vous vous attendez à ce que tous les sous-types de ConnectionAccessor aient quelque chose dont ils doivent disposer. Par conséquent, il semble préférable de s'assurer que le nettoyage correct est effectué (en termes d'appel GC.SuppressFinalize) par la classe de base plutôt que de dépendre de chaque sous-type pour le faire.

J'utilise le motif Éliminez mentionné dans le livre Bruce Wagners Effective C# qui est essentiellement:

public class BaseClass : IDisposable 
{ 
    private bool _disposed = false; 
    ~BaseClass() 
    { 
     Dispose(false); 
    } 

    public void Dispose() 
    { 
     Dispose(true); 
     GC.SuppressFinalize(true); 
    } 

    protected virtual void Dispose(bool disposing) 
    { 
     if (_disposed) 
      return; 

     if (disposing) 
     { 
      //release managed resources 
     } 

     //release unmanaged resources 

     _disposed = true; 
    } 
} 

public void Derived : BaseClass 
{ 
    private bool _disposed = false; 

    protected override void Dispose(bool disposing) 
    { 
     if (_disposed) 
      return; 

     if (disposing) 
     { 
      //release managed resources 
     } 

     //release unmanaged resources 

     base.Dispose(disposing); 
     _disposed = true; 
    } 

Answer 5

Le seul petit reproche que j'aurais avec les réponses fournies à ce jour est que tous supposent que vous besoin de avoir un finalisateur, ce qui n'est pas forcément le cas. Il y a un surcoût de performance assez important associé à la finalisation, que je ne voudrais pas imposer à toutes mes classes dérivées si ce n'était pas nécessaire. Voir this blog post par Joe Duffy, qui explique quand vous pouvez ou non avoir besoin d'un finaliseur, et comment implémenter correctement le pattern Dispose dans les deux cas.
Résumant l'article du blog de Joe, à moins que vous ne travailliez sur quelque chose de relativement bas traitant de la mémoire non gérée, vous ne devriez pas implémenter un finalizer. En règle générale, si votre classe ne contient que des références aux types gérés qui implémentent IDisposable eux-mêmes, vous n'avez pas besoin du finaliseur (mais devez implémenter IDisposable et disposer de ces ressources). Si vous allouez des ressources non managées directement à partir de votre code (PInvoke?) Et que ces ressources doivent être libérées, vous en avez besoin. Une classe dérivée peut toujours ajouter un finaliseur si elle en a vraiment besoin, mais forcer toutes les classes dérivées à avoir un finaliseur en la plaçant dans la classe de base provoque l'impact de toutes les classes dérivées sur la performance des objets finalisables. nécessaire.