La mise en œuvre de IDisposable sur une sous-classe lorsque le parent met également en œuvre IDisposable

J'ai un parent et un enfant de la classe que les deux ont besoin pour mettre en œuvre IDisposable. Où dois - virtual (et base.Dispose()?) les appels entrent en jeu? Quand je viens de remplacer le Dispose(bool disposing) appel, il se sent vraiment étrange disant que je n'en œuvre IDisposable sans avoir explicite Dispose() fonction (juste en utilisant l'héritage), mais ayant tout le reste.

Ce que j'avais fait (à banaliser un peu):

internal class FooBase : IDisposable
{
    Socket baseSocket;

    private void SendNormalShutdown() { }

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

    private bool _disposed = false;
    protected virtual void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            if (disposing)
            {
                SendNormalShutdown();
            }
            baseSocket.Close();
        }
    }

    ~FooBase()
    {
        Dispose(false);
    }
}

internal class Foo : FooBase, IDisposable
{
    Socket extraSocket;

    private bool _disposed = false;
    protected override void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            extraSocket.Close();
        }
        base.Dispose(disposing);
    }

    ~Foo()
    {
        Dispose(false);
    }

}

Msdn a publié des recommandations sur la façon de la sous-classe des objets de mise en œuvre de IDisposable.

InformationsquelleAutor Tanzelax | 2010-03-22

.net c#idisposable inheritance

26

Quand je viens de remplacer l'dispose(bool disposing) appel, il se sent vraiment étrange disant que je n'en œuvre IDisposable sans avoir explicite Dispose() fonction (juste en utilisant l'héritage), mais ayant tout le reste.

C'est quelque chose que vous ne devriez pas être concernés par.

Lorsque vous sous-classe d'une IDisposable classe, tout le "modèle dispose" la plomberie est déjà gérées par la classe de base. Vous devriez vraiment ne rien faire, mais remplacer le protected Dispose(bool) de la méthode et de vérifier si vous avez été éliminés déjà (pour bien élever ObjectDisposedException.)

Pour plus de détails, voir mon billet de blog sur Sous-classement à partir d'un IDisposable classe.

Aussi, souvent, c'est une bonne idée d'envisager l'encapsulation de l'IDisposable classe au lieu de sous-classement. Il ya des moments où un sous-classement IDisposable classe est approprié, mais ils sont assez rares. L'Encapsulation est souvent une meilleure solution.
- Ah, je suppose que mes inquiétudes étaient infondées et j'étais près à faire droite (je me demande d'où j'ai pris l'idée de re-mise en œuvre de l'outil de finalisation d'... oh bien). Et oui, l'héritage en général est quelque chose que je trouve moi-même à l'aide de moins en moins.
- Reed votre blog est génial... mais notez le nombre de réponse à votre question - 7 (1 est la mienne :)).... les gens ne peuvent pas goûtent assez sur ce point.. la honte.
InformationsquelleAutor Reed Copsey
5

Pourquoi compliquer les choses quand vous n'avez pas besoin de?

Puisque vous n'avez pas encapsuler toutes les ressources non managées, vous n'avez pas besoin de tout ça nettoie avec de finalisation. Et, vos classes sont à l'intérieur, ce qui suggère que vous avez le contrôle de la hiérarchie d'héritage au sein de votre assemblée.

Donc, l'compliqué approche serait:
```
internal class FooBase : IDisposable 
{ 
  Socket baseSocket; 

  private void SendNormalShutdown() 
  { 
    //...
  } 

  private bool _disposed = false; 

  public virtual void Dispose() 
  { 
    if (!_disposed)
    { 
      SendNormalShutdown(); 
      baseSocket.Close(); 
      _disposed = true;
    } 
  } 
} 

internal class Foo : FooBase
{ 
  Socket extraSocket; 

  private bool _disposed = false; 

  public override void Dispose()
  { 
    if (!_disposed)
    { 
      extraSocket.Close(); 
      _disposed = true;
    } 

    base.Dispose(); 
  } 
} 
```
Même si vous ne disposez pas des ressources non managées, je dirais que vous êtes beaucoup mieux les encapsulant dans leur propre classe jetables et de les utiliser comme vous l'auriez fait de toute autre jetables; aussi compliqué que le code ci-dessus.
- Pouvez-vous penser à tous les cas où une sous-classe doit avoir un nettoyage finaliseur lorsque l'un des parents de la classe n'a pas (à part le cas trivial d'hériter de l'Objet)? Je peux comprendre l'ajout d'un finaliseur dont le métier est de se plaindre de mal-objets abandonnés, mais à mon humble avis, tout ce qui requiert un nettoyage doit être dans son propre finalisable classe; je pense AUCUN exceptions.
- Je suis entièrement d' d'accord.
- Vous devez les empêcher d'écraser le public de Disposer de la méthode et, au lieu de remplacer la méthode protégée. Voir: docs.microsoft.com/en-us/dotnet/standard/garbage-collection/...
- Hey @DavidAnderson, il n'y a pas de méthode protégée, comme je ne suis pas à la suite de la Microsoft modèle pour les jetables sur le but. Jetez un oeil à mon approche, ici et ici.
InformationsquelleAutor Jordão
3

L'idée de ce modèle est que vous remplacez le virtuel Dispose méthode, en appelant base.Dispose si nécessaire. La classe de base prend en charge le reste, l'appel de la virtuel méthode dispose (et donc de la mise en œuvre correcte). Le sous-classe ne devrait pas avoir besoin de mettre en œuvre également IDisposable (c'est IDisposable via l'héritage)
- Je suppose que je pourrais juste prendre l'explicite : IDisposable, puisque c'est déjà héritant de l'interface. Je pense que je fais comme indiquant explicitement que "cette classe a des cédante qui se passe". Merci pour l'entrée, cependant. 🙂
InformationsquelleAutor spender
1

La classe enfant doit l'emporter sur le virtuel Disposer, effectuez l'une élimination spécifique à la sous-classe, et d'appeler la superclasse' en Disposer, ce qui à son tour fera de son propre travail.

EDIT: http://davybrion.com/blog/2008/06/disposing-of-the-idisposable-implementation/ est le modèle à suivre dans de tels cas. Pas le "Jetable" de la classe en particulier, mais de l'héritage et des remplacements.
- Je ne suis pas sûr que j'aime l'idée d'ajouter encore plus virtuel/méthodes abstraites de la déjà pléthorique IDisposable motif...
- À chacun son propre, je suppose. Le code fourni a été utile pour moi, où j'ai une hiérarchie de classes qui doivent être à usage unique. La plupart de l'installation est dans le top-niveau de la classe, et un minimum de code supplémentaire est nécessaire par la sous-classe.
InformationsquelleAutor Grant Palin

J'ai toujours se tourner vers Joe Duffy étude très approfondie sur ce modèle. Pour moi, sa version de l'Évangile.

http://joeduffyblog.com/2005/04/08/dg-update-dispose-finalization-and-resource-management/

La première chose à retenir est que un finaliseur n'est pas nécessaire la plupart du temps. C'est pour l'effacement des ressources non managées où vous êtes de détenir directement des ressources autochtones, c'est à dire uniquement les ressources qui n'ont pas leur propre outil de finalisation.

Voici un exemple pour une base de classe sous-classe de la paire.

//Base class

    #region IDisposable Members

    private bool _isDisposed;

    public void Dispose()
    {
        this.Dispose(true);
        //GC.SuppressFinalize(this); //Call after Dispose; only use if there is a finalizer.
    }

    protected virtual void Dispose(bool isDisposing)
    {
        if (!_isDisposed)
        {
            if (isDisposing)
            {
                //Clear down managed resources.

                if (this.Database != null)
                    this.Database.Dispose();
            }

            _isDisposed = true;
        }
    }

    #endregion


//Subclass

    #region IDisposable Members

    private bool _isDisposed;

    protected override void Dispose(bool isDisposing)
    {
        if (!_isDisposed)
        {
            if (isDisposing)
            {
                //Clear down managed resources.

                if (this.Resource != null)
                    this.Resource.Dispose();
            }

            _isDisposed = true;
        }

        base.Dispose(isDisposing);
    }

    #endregion

Noter que la sous-classe a sa propre _isDisposed membre. Notez également null-contrôle sur les ressources, puisque vous ne voulez pas des exceptions dans ces blocs.

Luc

InformationsquelleAutor Luke Puplett

Vous devez vous connecter pour publier un commentaire.