C# Desechar método abstracto

Question

tengo una clase abstracta que implementa IDisposable, así:

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

En Visual Studio Team System 2008, me encontré con el análisis de código en mi proyecto y una de las advertencias que se le ocurrió fue el siguiente:

Microsoft.Design: Modificar 'ConnectionAccessor.Dispose()' para que llame a Dispose (true), luego llama GC.SuppressFinalize en la instancia del objeto actual ('esto' o 'Yo' en Visual Basic), y luego regresa.

¿Es solo una tontería decirme que modifique el cuerpo de un método abstracto, o debo hacer algo más en cualquier instancia derivada de Dispose?

Answer 1

que debe seguir el patrón convencional para implementar Dispose. Hacer Dispose() virtual se considera mala práctica, porque el patrón convencional enfatiza la reutilización del código en "limpieza administrada" (cliente API llamando al Dispose() directamente o por using) y "limpieza no gestionada" (finalizador de llamadas del GC). Para recordar, el patrón es la siguiente:

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

clave aquí es que no hay duplicación entre finalizador y Dispose para la limpieza no administrado, y sin embargo ninguna clase derivada puede extender tanto la limpieza administrado y no administrado.

Para su caso, lo que debe hacer es lo siguiente:

protected abstract void Dispose(bool disposing) 

y dejar todo lo demás como es. Incluso eso tiene un valor dudoso, ya que ahora aplica sus clases derivadas para implementar Dispose, y ¿cómo sabe que todas las necesitan? Si su clase base no tiene nada que desechar, pero es probable que la mayoría de las clases derivadas sí lo hagan (con algunas excepciones), simplemente proporcione una implementación vacía. Es lo que hace System.IO.Stream (sí mismo abstracto), entonces hay un precedente.

Answer 2

La advertencia básicamente le dice que implemente el Dispose pattern en su clase.

El código resultante debe tener este aspecto:

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

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

    protected virtual void Dispose(bool disposing) 
    { 
    } 
} 

Answer 3

Sin embargo, la advertencia es interesante. Eric Lippert, uno de los diseñadores de C#, blogueó sobre por qué los mensajes de error deberían ser "Diagnósticos pero no preceptivos: describa el problema, no la solución". Read here.

Answer 4

A pesar de que parece un poco como puntillosa, el consejo es válido. Ya está indicando que espera que cualquier subtipo de ConnectionAccessor tenga algo que deben eliminar. Por lo tanto, parece mejor asegurarse de que la clase base realice la limpieza adecuada (en términos de la llamada GC.SuppressFinalize) en lugar de confiar en cada subtipo para hacerlo.

uso el patrón de disponer mencionado en el libro de Bruce Wagner Effective C# que es básicamente:

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

La única queja que tendría con las respuestas proporcionadas hasta ahora es que todos ellos suponen que necesidad de tener un finalizador, que no es necesariamente el caso. Hay una sobrecarga de rendimiento bastante significativa asociada con la finalización, que no quisiera imponer a todas mis clases derivadas si no fuera necesario.

Consulte this blog post por Joe Duffy, que explica cuándo puede necesitar o no un finalizador, y cómo implementar correctamente el patrón Eliminar en cualquier caso.
Resumiendo la publicación del blog de Joe, a menos que esté haciendo algo de bajo nivel relacionado con la memoria no administrada, no debe implementar un finalizador. Como regla general, si su clase solo contiene referencias a tipos administrados que implementan IDisposable por sí mismos, no necesita el finalizador (pero debe implementar IDisposable y disponer de esos recursos). Si está asignando recursos no administrados directamente desde su código (PInvoke?) Y esos recursos deben ser liberados, necesita uno. Una clase derivada siempre puede agregar un finalizador si realmente lo necesita, pero forzar a todas las clases derivadas a tener un finalizador al ponerlo en la clase base provoca que todas las clases derivadas se vean afectadas por el golpe de rendimiento de los objetos finalizables cuando esa sobrecarga no puede ser necesario.