Jak zapobiegasz rozprzestrzenianiu się IDisposable na wszystkie Twoje klasy?

Zacznij od tych prostych zajęć ...

Powiedzmy, że mam prosty zestaw klas, taki jak ten:

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 Busma Driver, Driverma dwa Shoes, każdy Shoema Shoelace. Bardzo głupie.

Dodaj obiekt IDisposable do Shoelace

Później zdecydowałem, że niektóre operacje na serwerze Shoelacemogą być wielowątkowe, więc dodaję EventWaitHandleznak, aby wątki się komunikowały. Więc Shoelaceteraz wygląda to tak:

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

Zaimplementuj IDisposable na Shoelace

Ale teraz FxCop Microsoftu będzie narzekał: „Zaimplementuj IDisposable na 'Shoelace', ponieważ tworzy elementy członkowskie następujących typów IDisposable: 'EventWaitHandle'."

Dobra, wdrażam IDisposabledalej Shoelacei moja zgrabna mała klasa staje się strasznym bałaganem:

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

Lub (jak podkreślają komentatorzy), ponieważ Shoelacesam nie ma niezarządzanych zasobów, mogę użyć prostszej implementacji usuwania bez potrzeby Dispose(bool)i 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);
    }
}

Oglądaj z przerażeniem, jak rozprzestrzenia się IDisposable

Tak, to naprawione. Ale teraz FxCop będzie narzekać, że Shoetworzy plik Shoelace, więc też Shoemusi być IDisposable.

I Drivertworzy Shoetak Drivermusi być IDisposable. I Bustworzy Drivertak Busmusi być IDisposablei tak dalej.

Nagle moja mała zmiana w aplikacji Shoelacepowoduje dużo pracy, a mój szef zastanawia się, dlaczego muszę się wymeldować, Busaby dokonać zmiany Shoelace.

Pytanie

Jak zapobiec temu rozprzestrzenianiu się IDisposable, ale jednocześnie zapewnić, że niezarządzane obiekty są prawidłowo usuwane?

Tak naprawdę nie można „zapobiec” rozprzestrzenianiu się IDisposable. Niektóre klasy muszą zostać usunięte, AutoResetEventa najbardziej efektywnym sposobem jest zrobienie tego w Dispose()metodzie, aby uniknąć narzutu finalizatorów. Ale ta metoda musi być jakoś wywołana, więc dokładnie tak, jak w twoim przykładzie klasy, które zawierają lub zawierają IDisposable, muszą je usunąć, więc muszą być również jednorazowe itp. Jedynym sposobem uniknięcia tego jest:

• unikaj używania klas IDisposable tam, gdzie to możliwe, blokuj lub czekaj na zdarzenia w pojedynczych miejscach, trzymaj drogie zasoby w jednym miejscu itp
• twórz je tylko wtedy, gdy ich potrzebujesz i wyrzucaj je zaraz po ( usingwzorze)

W niektórych przypadkach IDisposable można zignorować, ponieważ obsługuje opcjonalną wielkość liter. Na przykład WaitHandle implementuje IDisposable do obsługi nazwanego Mutex. Jeśli nazwa nie jest używana, metoda Dispose nic nie robi. MemoryStream to kolejny przykład, który nie używa żadnych zasobów systemowych, a jego implementacja Dispose również nic nie robi. Dokładne przemyślenie, czy niezarządzany zasób jest używany, czy nie, może być pouczające. Podobnie można sprawdzić dostępne źródła bibliotek .net lub użyć dekompilatora.

Jeśli chodzi o poprawność, nie można zapobiec rozprzestrzenianiu się IDisposable poprzez relację między obiektami, jeśli obiekt nadrzędny tworzy i zasadniczo jest właścicielem obiektu podrzędnego, który teraz musi być jednorazowy. FxCop jest poprawny w tej sytuacji, a rodzic musi być IDisposable.

Możesz uniknąć dodawania IDisposable do klasy liścia w hierarchii obiektów. Nie zawsze jest to łatwe zadanie, ale jest to ciekawe ćwiczenie. Z logicznego punktu widzenia nie ma powodu, dla którego sznurowadło musi być jednorazowe. Zamiast dodawać tutaj WaitHandle, można również dodać skojarzenie między ShoeLace i WaitHandle w miejscu, w którym jest używany. Najprostszym sposobem jest użycie instancji Dictionary.

Jeśli możesz przenieść WaitHandle do luźnego powiązania za pośrednictwem mapy w miejscu, w którym WaitHandle jest faktycznie używany, możesz przerwać ten łańcuch.

Aby zapobiec IDisposablerozprzestrzenianiu się, powinieneś spróbować hermetyzować użycie jednorazowego obiektu wewnątrz jednej metody. Spróbuj zaprojektować Shoelaceinaczej:

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

    } 

  }
} 

Zakres uchwytu oczekiwania jest ograniczony do Tie metody, a klasa nie musi mieć pola jednorazowego, a więc sama nie musi być jednorazowa.

Ponieważ uchwyt oczekiwania jest szczegółem implementacji wewnątrz elementu Shoelace, nie powinien on w żaden sposób zmieniać swojego publicznego interfejsu, na przykład poprzez dodanie nowego interfejsu w swojej deklaracji. Co się wtedy stanie, gdy nie będziesz już potrzebować pola jednorazowego, czy usuniesz IDisposabledeklarację? Jeśli pomyślisz o Shoelace abstrakcji , szybko zdasz sobie sprawę, że nie powinna być zanieczyszczona zależnościami infrastruktury, takimi jak IDisposable. IDisposablepowinny być zarezerwowane dla klas, których abstrakcja obejmuje zasób wymagający deterministycznego czyszczenia; tj. dla klas, w których rozporządzalność jest częścią abstrakcji .

Zasadniczo dzieje się tak, gdy mieszasz Kompozycję lub Agregację z klasami jednorazowymi. Jak wspomniano, pierwszym wyjściem byłoby zrefaktoryzowanie waitHandle z sznurówki.

Powiedziawszy to, możesz znacznie zmniejszyć wzorzec Disposable, gdy nie masz niezarządzanych zasobów. (Nadal szukam oficjalnego odniesienia do tego.)

Ale możesz pominąć destruktor i GC.SuppressFinalize (this); i może trochę wyczyścić wirtualną pustkę Dispose (bool dispose).

Co ciekawe, jeśli Driverzdefiniowano jak powyżej:

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

Wtedy, kiedy Shoejest zrobiony IDisposable, FxCop (v1.36) nie narzeka, że ​​tak Driverpowinno byćIDisposable .

Jednak jeśli jest zdefiniowane w ten sposób:

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

wtedy będzie narzekać.

Podejrzewam, że jest to tylko ograniczenie FxCop, a nie rozwiązanie, ponieważ w pierwszej wersji Shoeinstancje są nadal tworzone przez Driveri nadal trzeba je jakoś pozbyć.

Nie sądzę, aby istniał techniczny sposób zapobiegania rozprzestrzenianiu się IDisposable, jeśli projekt będzie tak ściśle powiązany. Należy się więc zastanowić, czy projekt jest właściwy.

W twoim przykładzie myślę, że sensowne jest, aby but miał sznurowadło, a może kierowca powinien posiadać swoje buty. Jednak autobus nie powinien być właścicielem kierowcy. Zazwyczaj kierowcy autobusów nie podążają za autobusami na złomowisko :) W przypadku kierowców i butów kierowcy rzadko robią własne buty, czyli tak naprawdę ich nie „posiadają”.

Alternatywnym projektem może być:

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

Nowy projekt jest niestety bardziej skomplikowany, ponieważ wymaga dodatkowych klas w celu utworzenia instancji i usunięcia konkretnych instancji butów i sterowników, ale ta komplikacja jest nieodłącznie związana z rozwiązywaniem problemu. Dobrą rzeczą jest to, że autobusy nie muszą już być jednorazowego użytku tylko w celu pozbycia się sznurowadeł.

A co powiesz na użycie 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))}));
        }
    }
}