Jak zapobiec rozprzestrzenianiu się IDisposable na wszystkie klasy?

Jeśli chodzi o poprawność, nie można zapobiec rozprzestrzenianiu się IDisposable poprzez relację obiektów, jeśli obiekt rodzic tworzy i zasadniczo posiada obiekt potomny, który musi być teraz jednorazowy. FxCop jest poprawny w tej sytuacji i rodzic musi być IDisposable.

Możesz uniknąć dodawania IDisposable do klasy leaf w hierarchii obiektów. Nie zawsze jest to łatwe zadanie, ale interesujące ćwiczenie. Z logicznego punktu widzenia nie ma powodu, aby Sznurowadła muszą być jednorazowe. Zamiast dodawać WaitHandle tutaj, jest to również możliwe, aby dodać skojarzenie między Sznurowadłem i WaitHandle w miejscu, w którym jest używany. Najprostszym sposobem jest wystąpienie słownika.

Jeśli możesz przenieść WaitHandle do luźnego związku za pomocą mapy w punkcie, w którym WaitHandle jest faktycznie używany, możesz przerwać ten łańcuch.

Aby zapobiec rozprzestrzenianiu się IDisposable, należy spróbować zamknąć użycie jednorazowego obiektu wewnątrz jednej metody. Spróbuj zaprojektować Shoelace inaczej:

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 rękojeści wait jest ograniczony do metody Tie, A klasa nie musi mieć pola jednorazowego użytku, więc sama nie musi być jednorazowa.

Ponieważ uchwyt oczekiwania jest szczegółem implementacji wewnątrz Shoelace, nie powinien zmieniać w żaden sposób swojego publicznego interfejsu, jak dodanie nowego interfejs w deklaracji. Co się stanie, gdy nie będzie już potrzebne pole jednorazowe, czy usuniesz deklarację IDisposable? Jeśli myślisz o Shoelace abstrakcja , szybko zdajesz sobie sprawę, że nie powinna być zanieczyszczana przez zależności infrastrukturalne, takie jak IDisposable. IDisposable powinny być zarezerwowane dla klas, których abstrakcja zawiera zasób, który wymaga deterministycznego oczyszczenia; tj. dla klas, w których dyspozycyjność jest częścią abstrakcji .

Wydaje się to bardzo podobne do kwestii projektowania wyższego poziomu, jak to często bywa, gdy "szybka naprawa" przekształca się w quagmire. Aby uzyskać więcej informacji na temat sposobów wyjścia, możesz znaleźć Ten wątek pomocny.

Co ciekawe, jeśli Driver jest zdefiniowane jak powyżej:

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

Wtedy gdy Shoe jest wykonane IDisposable, FxCop (v1.36) nie skarży się, że Driver powinno być również IDisposable.

Jeśli jednak jest zdefiniowany tak:

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 instancje Shoe są nadal tworzone przez Driver i nadal muszą być jakoś usunięte.

Myślę, że nie ma technicznego sposobu, aby zapobiec rozprzestrzenianiu się IDisposable, jeśli utrzymujesz swój projekt tak ściśle powiązany. Należy wtedy zastanawiać się, czy projekt jest właściwy.

W twoim przykładzie, myślę, że to ma sens, aby But był właścicielem sznurowadła, a może kierowca powinien mieć swoje buty. Jednak autobus nie powinien być właścicielem kierowcy. Zazwyczaj kierowcy autobusów nie jeżdżą 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 do tworzenia instancji i usuwania konkretnych przypadków butów i kierowców, ale ta komplikacja jest nieodłączna rozwiązywanemu problemowi. Dobrą rzeczą jest to, że autobusy nie muszą być już jednorazowe tylko w celu pozbycia się sznurowadeł.

To w zasadzie dzieje się, gdy mieszasz kompozycję lub agregację z klasami jednorazowymi. Jak wspomniano, pierwszym wyjściem będzie refaktoryzacja waitHandle z sznurowadła.

Powiedziawszy to, możesz rozebrać Jednorazowy wzór znacznie, gdy nie masz niezarządzanych zasobów. (Nadal szukam oficjalnego odniesienia do tego.)

Ale można pominąć Destruktor i GC.SuppressFinalize (this); a może czyszczenie wirtualnej pustki (bool pozbywanie się) trochę.

Jak o użyciu inwersji sterowania?

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