Implementierung von IDisposable für eine Unterklasse, wenn das übergeordnete Element auch IDisposable implementiert

Question

Ich habe eine übergeordnete und untergeordnete Klasse, die beide IDisposable implementieren müssen. Wohin sollen virtual (und base.Dispose()?) Anrufe ins Spiel kommen? Wenn ich gerade den Dispose(bool disposing) Anruf außer Kraft setze, fühlt es sich wirklich merkwürdig an, dass ich IDisposable ohne ausdrückliche Dispose() Funktion einführe (nur die geerbte verwendend), aber alles andere.

Was ich getan hatte (trivialisiert ziemlich viel):

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

} 

Answer 1

Wenn ich Entsorgen nur die außer Kraft setzen (bool disposing) Anruf, es fühlt sich wirklich seltsam besagt, dass ich IDisposable implementieren, ohne eine explizite Entsorgen mit() Funktion (nur die geerbte verwenden), aber alles andere.

Das ist etwas, worüber Sie nicht besorgt sein sollten.

Wenn Sie eine IDisposable-Klasse unterklassifizieren, wird die gesamte "Dispose pattern" -Sanierung bereits von der Basisklasse für Sie gehandhabt. Sie sollen sich wirklich nichts tun, sondern die protected Dispose(bool) Methode überschreiben, und verfolgen, ob Sie bereits angeordnet worden sind (richtig ObjectDisposedException zu erhöhen.)

Einzelheiten meiner Blog-Post auf Subclassing from an IDisposable class sehen.

---

auch oft, ist es eine gute Idee, Einkapseln der IDisposable Klasse zu betrachten, anstatt sie zu Subklassen. Es gibt Zeiten, in denen die Unterklasse einer IDisposable-Klasse sinnvoll ist, aber sie sind etwas selten. Die Verkapselung ist oft eine bessere Alternative.

Answer 2

Die Idee dieses Muster ist, dass man die virtuelle Dispose Methode überschreiben, rufen base.Dispose, falls erforderlich. Die Basisklasse erledigt den Rest und ruft die virtuelle Dispose-Methode (und damit die korrekte Implementierung) auf. Die Unterklasse sollte auch nicht IDisposable implementieren müssen (es ist IDisposable über Vererbung)

Answer 3

Die untergeordnete Klasse sollte die virtuelle Dispose außer Kraft setzen, eine spezifische Anordnung für die Unterklasse vornehmen und die Oberklasse 'Dispose' aufrufen, die wiederum ihre eigene Arbeit erledigt.

EDIT: http://davybrion.com/blog/2008/06/disposing-of-the-idisposable-implementation/ ist das Muster, das ich in solchen Fällen befolge. Nicht die "Disposable" -Klasse speziell, sondern die Vererbung und Außerkraftsetzung.

Answer 4

Warum Dinge komplizieren, wenn Sie nicht brauchen?

Da Sie keine nicht verwalteten Ressourcen einkapseln, brauchen Sie nicht alles, was mit der Finalisierung zu tun hat. Und Ihre Klassen sind intern, was darauf hindeutet, dass Sie die Vererbungshierarchie in Ihrer eigenen Assembly steuern.

So würde der straighforward Ansatz:

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(); 
    } 
} 

Auch wenn Sie nicht verwalteten Ressourcen zu tun haben, würde ich sagen, Sie sind viel besser dran encapsulating them in ihrer eigenen Einweg-Klasse und mit ihnen wie würden Sie Verwenden Sie andere Einwegartikel; so geradlinig wie der obige Code.

Answer 5

Ich wende mich immer an Joe Duffys sehr eingehende Studie zu diesem Muster. Für mich ist seine Version Gospel.

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

Das erste, was zu erinnern ist, dass ein Finalizerthread nicht die meiste Zeit benötigt wird. Es dient zur Bereinigung nicht verwalteter Ressourcen, in denen Sie direkt native Ressourcen halten, d. H. Nur Ressourcen, die keinen eigenen Finalizer haben.

Hier ist ein Beispiel für ein Basisklasse-Unterklassenpaar.

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

Beachten Sie, dass die Unterklasse ein eigenes Element _isDisposed hat. Notieren Sie auch die Ressourcen, da Sie keine Ausnahmen in diesen Blöcken wünschen.

Luke