Come si impedisce a IDisposable di diffondersi in tutte le classi?

Inizia con queste semplici classi ...

Diciamo che ho un semplice set di classi come questo:

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 Busha a Driver, Driverha due Shoes, ognuna Shoeha a Shoelace. Tutto molto sciocco.

Aggiungi un oggetto IDisposable a Laccio

In seguito decido che alcune operazioni su Shoelacepotrebbero essere multi-thread, quindi aggiungo un messaggio EventWaitHandleper comunicare con i thread. Quindi Shoelaceora appare così:

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

Implementare IDisposable su Shoelace

Ma ora FxCop di Microsoft si lamenterà: "Implementa IDisposable su 'Shoelace' perché crea membri dei seguenti tipi IDisposable: 'EventWaitHandle'."

Va bene, implemento IDisposablesu Shoelacee la mia classe di poco pulito diviene questa orribile pasticcio:

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

Oppure (come sottolineato dai commentatori) poiché di per Shoelacesé non ha risorse non gestite, potrei usare l'implementazione di smaltimento più semplice senza la necessità di Dispose(bool)e Destructor:

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

Guarda con orrore gli spread IDisposable

Esatto, è quello risolto. Ma ora FxCop si lamenterà che Shoecrea un Shoelace, così Shoedeve essere IDisposableanche.

E Drivercrea Shoecosì Driverdeve essere IDisposable. E Buscrea Drivercosì Busdeve essere IDisposablee così via.

Improvvisamente la mia piccola modifica Shoelacemi sta causando molto lavoro e il mio capo si chiede perché devo fare il checkout Busper fare una modifica Shoelace.

La domanda

Come evitare questa diffusione di IDisposable, ma garantire comunque che gli oggetti non gestiti siano correttamente smaltiti?

Non puoi davvero "impedire" la diffusione di IDisposable. Alcune classi devono essere disposte, come AutoResetEvent, e il modo più efficace è farlo nel Dispose()metodo per evitare il sovraccarico dei finalizzatori. Ma questo metodo deve essere chiamato in qualche modo, così esattamente come nel tuo esempio le classi che incapsulano o contengono IDisposable devono smaltirle, quindi devono anche essere usa e getta, ecc. L'unico modo per evitarlo è:

• evitare l'uso di classi IDisposable ove possibile, bloccare o attendere eventi in singoli luoghi, mantenere costose risorse in un unico posto, ecc
• crearli solo quando ne hai bisogno e smaltirli subito dopo (lo usingschema)

In alcuni casi, IDisposable può essere ignorato perché supporta un caso opzionale. Ad esempio, WaitHandle implementa IDisposable per supportare un Mutex denominato. Se non viene utilizzato un nome, il metodo Dispose non fa nulla. MemoryStream è un altro esempio, non utilizza risorse di sistema e anche l'implementazione di Dispose non fa nulla. Un'attenta riflessione sull'utilizzo o meno di una risorsa non gestita può essere istruttiva. Così può esaminare le fonti disponibili per le librerie .net o usare un decompilatore.

In termini di correttezza, non è possibile impedire la diffusione di IDisposable attraverso una relazione di oggetto se un oggetto padre crea e essenzialmente possiede un oggetto figlio che deve ora essere disponibile. FxCop è corretto in questa situazione e il genitore deve essere IDisposable.

Quello che puoi fare è evitare di aggiungere un IDisposable a una classe foglia nella gerarchia degli oggetti. Questo non è sempre un compito facile ma è un esercizio interessante. Dal punto di vista logico, non vi è alcun motivo per cui una scarpa deve essere usa e getta. Invece di aggiungere un WaitHandle qui, è anche possibile aggiungere un'associazione tra un ShoeLace e un WaitHandle nel punto in cui viene utilizzato. Il modo più semplice è tramite un'istanza del dizionario.

Se puoi spostare WaitHandle in un'associazione libera tramite una mappa nel punto in cui WaitHandle viene effettivamente utilizzato, puoi interrompere questa catena.

Per evitare la IDisposablediffusione, dovresti provare a incapsulare l'uso di un oggetto usa e getta all'interno di un singolo metodo. Prova a progettare Shoelacediversamente:

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

    } 

  }
} 

L'ambito della maniglia di attesa è limitato a Tie metodo e la classe non ha bisogno di avere un campo usa e getta, quindi non dovrà essere usa e getta da sola.

Poiché l'handle wait è un dettaglio di implementazione all'interno di Shoelace, non dovrebbe in alcun modo cambiare la sua interfaccia pubblica, come aggiungere una nuova interfaccia nella sua dichiarazione. Cosa succederà quindi quando non avrai più bisogno di un campo monouso, rimuoverai la IDisposabledichiarazione? Se pensi Shoelace all'astrazione , ti rendi presto conto che non dovrebbe essere inquinato dalle dipendenze dell'infrastruttura, come IDisposable. IDisposabledovrebbe essere riservato alle classi la cui astrazione incapsula una risorsa che richiede una pulizia deterministica; vale a dire, per le classi in cui la disponibilità è parte dell'astrazione .

Questo è fondamentalmente ciò che accade quando si mescolano le classi Composizione o Aggregazione con Classi usa e getta. Come accennato, la prima via d'uscita sarebbe quella di refactoring l'attesaHandle fuori dai lacci delle scarpe.

Detto questo, è possibile ridurre considerevolmente il modello Monouso quando non si hanno risorse non gestite. (Sto ancora cercando un riferimento ufficiale per questo.)

Ma puoi omettere il distruttore e GC.SuppressFinalize (questo); e forse ripulire un po 'il vuoto virtuale Dispose (bool disposing).

È interessante notare se Driverè definito come sopra:

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

Quindi quando Shoeviene creato IDisposable, FxCop (v1.36) non si lamenta che Driverdovrebbe esserloIDisposable .

Tuttavia, se definito in questo modo:

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

allora si lamenterà.

Ho il sospetto che questa sia solo una limitazione di FxCop, piuttosto che una soluzione, perché nella prima versione le Shoeistanze vengono ancora create da Drivere devono comunque essere eliminate in qualche modo.

Non credo che esista un modo tecnico per impedire la diffusione di IDisposable se il tuo design è così strettamente accoppiato. Ci si dovrebbe quindi chiedere se il design sia giusto.

Nel tuo esempio, penso che abbia senso avere la scarpa propria del laccio, e forse il conducente dovrebbe possedere le sue scarpe. Tuttavia, il bus non dovrebbe possedere l'autista. In genere, i conducenti di autobus non seguono gli autobus fino allo scalo :) Nel caso di conducenti e scarpe, raramente i conducenti si fabbricano le proprie scarpe, il che significa che non le "possiedono" realmente.

Un design alternativo potrebbe essere:

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

Il nuovo design è purtroppo più complicato, in quanto richiede ulteriori classi per istanziare e smaltire esempi concreti di scarpe e driver, ma questa complicazione è inerente al problema da risolvere. La cosa buona è che gli autobus non devono più essere usa e getta semplicemente allo scopo di smaltire i lacci delle scarpe.

Che ne dici di usare Inversion of 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))}));
        }
    }
}