Comment empêchez-vous IDisposable de se propager dans toutes vos classes?

Commencez par ces classes simples ...

Disons que j'ai un simple ensemble de classes comme celui-ci:

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 Busa un Driver, le Drivera deux Shoes, chacun Shoea un Shoelace. Tout cela est très idiot.

Ajouter un objet IDisposable à Shoelace

Plus tard, je décide qu'une opération sur le Shoelacepourrait être multi-thread, donc j'ajoute un EventWaitHandlepour les threads avec lesquels communiquer. Alors Shoelacemaintenant ressemble à ceci:

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

Implémenter IDisposable sur Shoelace

Mais maintenant FxCop de Microsoft se plaindra: "Implémentez IDisposable sur 'Shoelace' car il crée des membres des types IDisposable suivants: 'EventWaitHandle'."

D' accord, je mets en œuvre IDisposablesur Shoelaceet ma petite classe propre cette horrible gâchis devient:

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

Ou (comme l'ont souligné les commentateurs) étant donné que Shoelacelui-même n'a pas de ressources non gérées, je pourrais utiliser l'implémentation plus simple de dispose sans avoir besoin de Dispose(bool)et 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);
    }
}

Regardez avec horreur alors que IDisposable se propage

C'est bien ça fixe. Mais maintenant FxCop se plaindra que Shoecrée un Shoelace, donc Shoedoit l'être IDisposableaussi.

Et Drivercrée Shoeainsi Driverdoit être IDisposable. Et Buscrée Driverainsi Busdoit être IDisposableet ainsi de suite.

Soudain, mon petit changement Shoelaceme cause beaucoup de travail et mon patron se demande pourquoi je dois payer Buspour faire un changement Shoelace.

La question

Comment éviter cette propagation IDisposable, tout en vous assurant que vos objets non gérés sont correctement éliminés?

Vous ne pouvez pas vraiment «empêcher» IDisposable de se propager. Certaines classes doivent être supprimées, par exemple AutoResetEvent, et le moyen le plus efficace est de le faire dans la Dispose()méthode pour éviter la surcharge des finaliseurs. Mais cette méthode doit être appelée d'une manière ou d'une autre, donc exactement comme dans votre exemple, les classes qui encapsulent ou contiennent IDisposable doivent les éliminer, elles doivent donc également être jetables, etc. La seule façon de l'éviter est de:

• évitez d'utiliser les classes IDisposable lorsque cela est possible, verrouillez ou attendez des événements dans des endroits uniques, conservez des ressources coûteuses en un seul endroit, etc.
• créez-les uniquement lorsque vous en avez besoin et jetez-les juste après (le usingmotif)

Dans certains cas, IDisposable peut être ignoré car il prend en charge un cas facultatif. Par exemple, WaitHandle implémente IDisposable pour prendre en charge un Mutex nommé. Si aucun nom n'est utilisé, la méthode Dispose ne fait rien. MemoryStream est un autre exemple, il n'utilise aucune ressource système et son implémentation Dispose ne fait rien non plus. Une réflexion approfondie sur l'utilisation ou non d'une ressource non gérée peut être une instruction. Ainsi peut examiner les sources disponibles pour les bibliothèques .net ou utiliser un décompilateur.

En termes d'exactitude, vous ne pouvez pas empêcher la propagation de IDisposable via une relation d'objet si un objet parent crée et possède essentiellement un objet enfant qui doit maintenant être jetable. FxCop est correct dans cette situation et le parent doit être IDisposable.

Ce que vous pouvez faire, c'est éviter d'ajouter un IDisposable à une classe feuille dans votre hiérarchie d'objets. Ce n'est pas toujours une tâche facile mais c'est un exercice intéressant. D'un point de vue logique, il n'y a aucune raison pour laquelle un ShoeLace doit être jetable. Au lieu d'ajouter un WaitHandle ici, il est également possible d'ajouter une association entre un ShoeLace et un WaitHandle au point où il est utilisé. Le moyen le plus simple consiste à utiliser une instance de Dictionary.

Si vous pouvez déplacer le WaitHandle dans une association lâche via une carte au point où le WaitHandle est réellement utilisé, vous pouvez rompre cette chaîne.

Pour éviter IDisposablede se propager, vous devriez essayer d'encapsuler l'utilisation d'un objet jetable à l'intérieur d'une seule méthode. Essayez de concevoir Shoelacedifféremment:

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

    } 

  }
} 

La portée du handle d'attente est limitée à la Tieméthode, et la classe n'a pas besoin d'avoir un champ jetable, et n'a donc pas besoin d'être elle-même jetable.

Puisque le handle d'attente est un détail d'implémentation à l'intérieur de Shoelace, il ne devrait en aucun cas changer son interface publique, comme l'ajout d'une nouvelle interface dans sa déclaration. Que se passera-t-il alors si vous n'avez plus besoin d'un champ jetable, supprimerez-vous la IDisposabledéclaration? Si vous pensez à l' Shoelace abstraction , vous vous rendez vite compte qu'elle ne devrait pas être polluée par des dépendances d'infrastructure, comme IDisposable. IDisposabledevrait être réservé aux classes dont l'abstraction encapsule une ressource qui appelle un nettoyage déterministe; c'est-à-dire pour les classes où la disponibilité fait partie de l' abstraction .

C'est essentiellement ce qui se passe lorsque vous mélangez la composition ou l'agrégation avec des classes jetables. Comme mentionné, la première solution serait de refactoriser le waitHandle hors du lacet.

Cela dit, vous pouvez réduire considérablement le modèle jetable lorsque vous ne disposez pas de ressources non gérées. (Je cherche toujours une référence officielle pour cela.)

Mais vous pouvez omettre le destructeur et GC.SuppressFinalize (this); et peut-être nettoyer un peu le vide virtuel Dispose (suppression des booléens).

Fait intéressant si Driverest défini comme ci-dessus:

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

Ensuite, quand Shoec'est fait IDisposable, FxCop (v1.36) ne se plaint pas qui Driverdevrait aussi l'être IDisposable.

Cependant, s'il est défini comme ceci:

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

alors il se plaindra.

Je soupçonne que ce n'est qu'une limitation de FxCop, plutôt qu'une solution, car dans la première version, les Shoeinstances sont toujours créées par le Driveret doivent toujours être supprimées.

Je ne pense pas qu'il existe un moyen technique d'empêcher IDisposable de se propager si vous gardez votre conception si étroitement couplée. Il faut alors se demander si le design est correct.

Dans votre exemple, je pense qu'il est logique que la chaussure possède le lacet, et peut-être que le conducteur devrait posséder ses chaussures. Cependant, le bus ne devrait pas posséder le conducteur. En règle générale, les chauffeurs de bus ne suivent pas les bus jusqu'à la casse :) Dans le cas des chauffeurs et des chaussures, les chauffeurs fabriquent rarement leurs propres chaussures, ce qui signifie qu'ils ne les «possèdent» pas vraiment.

Une conception alternative pourrait être:

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

La nouvelle conception est malheureusement plus compliquée, car elle nécessite des classes supplémentaires pour instancier et éliminer des instances concrètes de chaussures et de pilotes, mais cette complication est inhérente au problème en cours de résolution. La bonne chose est que les bus ne doivent plus être jetables simplement pour se débarrasser des lacets.

Que diriez-vous d'utiliser l'inversion de contrôle?

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