¿Cómo evita que IDisposable se propague a todas sus clases?

Comience con estas clases simples ...

Digamos que tengo un conjunto simple de clases como esta:

class Bus
{
    Driver busDriver = new Driver();
}

class Driver
{
    Shoe[] shoes = { new Shoe(), new Shoe() };
}

class Shoe
{
    Shoelace lace = new Shoelace();
}

class Shoelace
{
    bool tied = false;
}

A Bustiene a Driver, Drivertiene dos Shoes, cada uno Shoetiene a Shoelace. Todo muy tonto.

Agregue un objeto IDisposable a Shoelace

Más tarde decido que alguna operación en el Shoelacepodría ser multiproceso, así que agrego un EventWaitHandlepara que los hilos se comuniquen. Entonces Shoelaceahora se ve así:

class Shoelace
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;
    // ... other stuff ..
}

Implemento IDisposable en Cordón

Pero ahora FxCop de Microsoft se quejará: "Implemente IDisposable en 'Shoelace' porque crea miembros de los siguientes tipos de IDisposable: 'EventWaitHandle'".

Está bien, puedo aplicar IDisposableen Shoelacey mi clase se convierte en poco aseado este horrible desastre:

class Shoelace : IDisposable
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;
    private bool disposed = false;

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

    ~Shoelace()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!this.disposed)
        {
            if (disposing)
            {
                if (waitHandle != null)
                {
                    waitHandle.Close();
                    waitHandle = null;
                }
            }
            // No unmanaged resources to release otherwise they'd go here.
        }
        disposed = true;
    }
}

O (como lo señalaron los comentaristas) ya que en Shoelacesí mismo no tiene recursos no administrados, podría usar la implementación de disposición más simple sin necesidad de Dispose(bool)Destructor y:

class Shoelace : IDisposable
{
    private AutoResetEvent waitHandle = new AutoResetEvent(false);
    bool tied = false;

    public void Dispose()
    {
        if (waitHandle != null)
        {
            waitHandle.Close();
            waitHandle = null;
        }
        GC.SuppressFinalize(this);
    }
}

Mire con horror cómo se propaga IDisposable

Correcto, eso es todo arreglado. Pero ahora FxCop se quejará de que Shoecrea un Shoelace, por Shoelo que IDisposabletambién debe ser .

Y Drivercrea Shoeasí Driverdebe ser IDisposable. Y Buscrea Driverasí Busdebe ser IDisposabley así sucesivamente.

De repente, mi pequeño cambio Shoelaceme está causando mucho trabajo y mi jefe se pregunta por qué tengo que pagar Buspara hacer un cambio Shoelace.

La pregunta

¿Cómo evita esta propagación IDisposable, pero se asegura de que sus objetos no gestionados se eliminen correctamente?

Realmente no puede "evitar" que se propague IDisposable. Algunas clases deben eliminarse, como AutoResetEvent, y la forma más eficiente es hacerlo en el Dispose()método para evitar la sobrecarga de los finalizadores. Pero este método debe llamarse de alguna manera, por lo que exactamente como en su ejemplo, las clases que encapsulan o contienen IDisposable deben eliminarlos, por lo que también deben ser desechables, etc. La única forma de evitarlo es:

• evite usar clases IDisposable cuando sea posible, bloquee o espere eventos en lugares únicos, mantenga recursos caros en un solo lugar, etc.
• créelos solo cuando los necesite y deséchelos justo después (el usingpatrón)

En algunos casos, IDisposable se puede ignorar porque admite un caso opcional. Por ejemplo, WaitHandle implementa IDisposable para admitir un Mutex con nombre. Si no se usa un nombre, el método Dispose no hace nada. MemoryStream es otro ejemplo, no utiliza recursos del sistema y su implementación Dispose tampoco hace nada. Pensar cuidadosamente si un recurso no administrado se está utilizando o no puede ser instructivo. También puede examinar las fuentes disponibles para las bibliotecas .net o usar un descompilador.

En términos de corrección, no puede evitar la propagación de IDisposable a través de una relación de objeto si un objeto padre crea y posee esencialmente un objeto hijo que ahora debe ser desechable. FxCop es correcto en esta situación y el padre debe ser IDisposable.

Lo que puede hacer es evitar agregar un IDisposable a una clase de hoja en su jerarquía de objetos. Esto no siempre es una tarea fácil, pero es un ejercicio interesante. Desde una perspectiva lógica, no hay razón para que un ShoeLace deba ser desechable. En lugar de agregar un WaitHandle aquí, también es posible agregar una asociación entre un ShoeLace y un WaitHandle en el punto en que se usa. La forma más simple es a través de una instancia de Diccionario.

Si puede mover WaitHandle a una asociación suelta a través de un mapa en el punto en que se utiliza WaitHandle, puede romper esta cadena.

Para evitar la IDisposablepropagación, debe intentar encapsular el uso de un objeto desechable dentro de un único método. Intenta diseñar de manera Shoelacediferente:

class Shoelace { 
  bool tied = false; 

  public void Tie() {

    using (var waitHandle = new AutoResetEvent(false)) {

      // you can even pass the disposable to other methods
      OtherMethod(waitHandle);

      // or hold it in a field (but FxCop will complain that your class is not disposable),
      // as long as you take control of its lifecycle
      _waitHandle = waitHandle;
      OtherMethodThatUsesTheWaitHandleFromTheField();

    } 

  }
} 

El alcance del controlador de espera está limitado al Tiemétodo, y la clase no necesita tener un campo desechable, por lo que no será necesario que sea desechable.

Dado que el identificador de espera es un detalle de implementación dentro del Shoelace, no debe cambiar de ninguna manera su interfaz pública, como agregar una nueva interfaz en su declaración. ¿Qué sucederá entonces cuando ya no necesite un campo desechable, eliminará la IDisposabledeclaración? Si piensa en la Shoelace abstracción , rápidamente se da cuenta de que no debería estar contaminada por dependencias de infraestructura, como IDisposable. IDisposabledebe reservarse para clases cuya abstracción encapsule un recurso que requiera una limpieza determinista; es decir, para clases donde la disposición es parte de la abstracción .

Esto es básicamente lo que sucede cuando mezclas Composición o Agregación con clases desechables. Como se mencionó, la primera salida sería refactorizar el waitHandle sin cordones.

Dicho esto, puede eliminar considerablemente el patrón Desechable cuando no tiene recursos no administrados. (Todavía estoy buscando una referencia oficial para esto).

Pero puede omitir el destructor y GC.SuppressFinalize (esto); y tal vez limpie un poco el virtual virtual Dispose (bool disposing).

Curiosamente, si Driverse define como anteriormente:

class Driver
{
    Shoe[] shoes = { new Shoe(), new Shoe() };
}

Luego, cuando Shoese realiza IDisposable, FxCop (v1.36) no se queja de que Drivertambién debería ser IDisposable.

Sin embargo, si se define así:

class Driver
{
    Shoe leftShoe = new Shoe();
    Shoe rightShoe = new Shoe();
}

entonces se quejará.

Sospecho que esto es solo una limitación de FxCop, en lugar de una solución, porque en la primera versión, las Shoeinstancias todavía están siendo creadas por Drivery todavía deben eliminarse de alguna manera.

No creo que haya una forma técnica de evitar que se propague IDisposable si mantiene su diseño tan estrechamente acoplado. Uno debería preguntarse si el diseño es correcto.

En su ejemplo, creo que tiene sentido que el zapato sea dueño del cordón, y tal vez, el conductor debería tener sus zapatos. Sin embargo, el autobús no debe ser dueño del conductor. Por lo general, los conductores de autobuses no siguen los autobuses hasta el depósito de chatarra :) En el caso de los conductores y los zapatos, los conductores rara vez hacen sus propios zapatos, lo que significa que realmente no los "poseen".

Un diseño alternativo podría ser:

class Bus
{
   IDriver busDriver = null;
   public void SetDriver(IDriver d) { busDriver = d; }
}

class Driver : IDriver
{
   IShoePair shoes = null;
   public void PutShoesOn(IShoePair p) { shoes = p; }
}

class ShoePairWithDisposableLaces : IShoePair, IDisposable
{
   Shoelace lace = new Shoelace();
}

class Shoelace : IDisposable
{
   ...
}

Desafortunadamente, el nuevo diseño es más complicado, ya que requiere clases adicionales para crear instancias y eliminar instancias concretas de zapatos y conductores, pero esta complicación es inherente al problema que se está resolviendo. Lo bueno es que los autobuses ya no necesitan ser desechables simplemente con el fin de deshacerse de los cordones de los zapatos.

¿Qué tal usar la Inversión de Control?

class Bus
{
    private Driver busDriver;

    public Bus(Driver busDriver)
    {
        this.busDriver = busDriver;
    }
}

class Driver
{
    private Shoe[] shoes;

    public Driver(Shoe[] shoes)
    {
        this.shoes = shoes;
    }
}

class Shoe
{
    private Shoelace lace;

    public Shoe(Shoelace lace)
    {
        this.lace = lace;
    }
}

class Shoelace
{
    bool tied;
    private AutoResetEvent waitHandle;

    public Shoelace(bool tied, AutoResetEvent waitHandle)
    {
        this.tied = tied;
        this.waitHandle = waitHandle;
    }
}

class Program
{
    static void Main(string[] args)
    {
        using (var leftShoeWaitHandle = new AutoResetEvent(false))
        using (var rightShoeWaitHandle = new AutoResetEvent(false))
        {
            var bus = new Bus(new Driver(new[] {new Shoe(new Shoelace(false, leftShoeWaitHandle)),new Shoe(new Shoelace(false, rightShoeWaitHandle))}));
        }
    }
}