Zadeklarować IDisposable dla klasy lub interfejsu?

Question

Począwszy od follwing sytuacji:

public interface ISample 
{ 
} 

public class SampleA : ISample 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

public class SampleB : ISample 
{ 
    // has no resources that needs to be disposed 
} 

Klasa SampleA powinny wdrożyć IDisposable interfejsu do zwalniania zasobów. Można to rozwiązać na dwa sposoby:

1. Dodać wymaganą interfejs klasy SampleA:

public class SampleA : ISample, IDisposable 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

2. dodać go do ISample interfejsu i siła wynikająca zajęcia do jego realizacji:

public interface ISample : IDisposable 
{ 
} 

Jeśli wstawisz go do interfejsu wymusić realizację dowolnego celu realizacji IDisposable, nawet jeśli nie mają nic do dysponowania. Z drugiej strony bardzo wyraźnie widać, że konkretna implementacja interfejsu wymaga bloku utylizacji/używania i nie trzeba go używać jako odczytywalnego do czyszczenia. Może być trochę plusów/minusów w obie strony ... dlaczego sugerowałbyś, aby preferować jedną preferowaną metodę?

Answer 1

Jeśli stosuje się wzór using(){} do wszystkich interfejsów najlepiej mieć ISample pochodzą z IDisposable ponieważ zasada przy projektowaniu interfejsów ma sprzyjać „łatwość użytkowania” nad „łatwość wdrożenia ".

Answer 2

Osobiście, jeśli wszystkie ISample powinny być jednorazowe, umieściłbym je na interfejsie, jeśli tylko niektóre z nich umieściłem tylko na zajęciach, gdzie powinno być.

Wygląda na to, że masz drugi przypadek.

Answer 3

Osobiście wybrałbym 1, chyba że podasz konkretny przykład dla dwóch osób. Dobrym przykładem dwóch jest IList.

An IList oznacza, że ​​musisz zaimplementować indeksator swojej kolekcji. Jednak IList oznacza również, że jesteś IEnumerable i powinieneś mieć GetEnumerator() dla swojej klasy.

W twoim przypadku masz wahaliśmy że klasy, które implementują ISample musiałby realizować IDisposable, jeśli nie każda klasa, która implementuje interfejs musi wdrożyć IDisposable to nie ich zmusić.

Koncentrując się na IDispoable w szczególności, IDispoable w szczególności zmusza programistów używających twojej klasy do napisania jakiegoś rozsądnie brzydkiego kodu. Na przykład,

foreach(item in IEnumerable<ISample> items) 
{ 
    try 
    { 
     // Do stuff with item 
    } 
    finally 
    { 
     IDisposable amIDisposable = item as IDisposable; 
     if(amIDisposable != null) 
      amIDisposable.Dispose(); 
    } 
} 

Nie tylko jest kod straszne, nie będzie znacząca kara wydajność w zapewnieniu jest wreszcie blokować do dysponowania rzeczą dla każdej iteracji tej liście, nawet jeśli Dispose() tylko powraca w realizacja.

Wkleiłem kod, aby odpowiedzieć na jeden z komentarzy tutaj, łatwiejszy do odczytania.

Answer 4

IDispoable to bardzo często spotykany interfejs, nic więc dziwnego, że dziedziczy po nim interfejs. W ten sposób unikniesz sprawdzania typu w kodzie za jedyne koszty, aby w niektórych implementacjach ISample implementacja nie była wykonywana. Tak więc twój drugi wybór może być lepszy z tego punktu widzenia.

Answer 5

interfejs IFoo prawdopodobnie powinien wdrożyć IDisposable jeżeli jest prawdopodobne, że przynajmniej niektóre niektóre implementacje wdroży IDisposable, a przynajmniej niektórych przypadkach ostatnia wzmianka życiu do instancji będą przechowywane w zmiennej lub pola typu IFoo. Powinno to prawie na pewno zaimplementować IDisposable, jeśli jakiekolwiek implementacje mogą zaimplementować IDisposable, a instancje zostaną utworzone za pośrednictwem interfejsu fabrycznego (tak jak w przypadku instancji IEnumerator<T>, które w wielu przypadkach są tworzone za pomocą interfejsu fabrycznego IEnumerable<T>).

Porównywanie IEnumerable<T> i IEnumerator<T> jest pouczające. Niektóre typy implementujące IEnumerable<T> również implementują IDisposable, ale kod, który tworzy wystąpienia takich typów, będzie wiedział, czym one są, wiedzą, że wymagają utylizacji i używają ich jako swoich konkretnych typów. Takie instancje mogą zostać przekazane do innych procedur jako typ IEnumerable<T>, a te inne procedury nie miałyby żadnej wskazówki, że obiekty ostatecznie będą wymagały utylizacji, ale te inne procedury w większości przypadków nie byłyby ostatnimi, które utrzymywałyby odniesienia do obiektów.. Z kolei instancje IEnumerator<T> są często tworzone, używane i ostatecznie odrzucane przez kod, który nie wie nic o podstawowych typach tych instancji poza faktem, że zostały zwrócone przez IEnumerable<T>. Niektóre implementacje powrotnych implementacji z IEnumerator<T> będą przeciekać zasoby, jeśli ich metoda IDisposable.Dispose nie zostanie wywołana, zanim zostaną one porzucone, a większość kodu, który akceptuje parametry typu IEnumerable<T>, nie będzie w stanie ustalić, czy takie typy mogą być do niego przekazywane. Chociaż byłoby możliwe, aby IEnumerable<T> zawrzeć właściwość EnumeratorTypeNeedsDisposal, aby wskazać, czy zwrócona IEnumerator<T> musiałaby zostać usunięta, lub po prostu wymagać, aby procedury, które wywołują GetEnumerator() sprawdzają typ zwróconego obiektu, aby zobaczyć, czy implementuje on IDisposable, jest to szybsze i łatwiejsze aby bezwarunkowo wywołać metodę Dispose, która może nie zrobić nic, niż określić, czy jest ona konieczna i zadzwonić do niej tylko wtedy, gdy tak jest.

Answer 6

Po Inteface Segregation Principle z SOLID jeśli dodać IDisposable do interfejsu dajesz metod do klientów, którzy nie są zainteresowani, więc należy go dodać do A.

Poza tym interfejs jest jednorazowy, ponieważ nigdy dyspozycyjność jest czymś związanym z konkretną implementacją interfejsu, nigdy z samym interfejsem.

Każdy interfejs może być potencjalnie zaimplementowany z elementami lub bez elementów, które należy usunąć.

Answer 7

Zaczynam myśleć, że umieszczenie IDisposable na interfejsie może spowodować pewne problemy. Oznacza to, że czas życia wszystkich obiektów implementujących ten interfejs może być bezpiecznie synchronicznie zakończony. To znaczy, że pozwala ktoś napisać kod w ten sposób i wymaga wszystkie implementacje wspierać IDisposable:

using (ISample myInstance = GetISampleInstance()) 
{ 
    myInstance.DoSomething(); 
} 

tylko kod, który uzyskuje dostęp do betonu typu może znać odpowiedni sposób kontrolować żywotność obiektu.Na przykład typ może nie wymagać usuwania, może obsługiwać IDisposable lub może wymagać pewnego asynchronicznego procesu czyszczenia po zakończeniu korzystania z niego (np. something like option 2 here).

Autor interfejsu nie jest w stanie przewidzieć wszystkich możliwych potrzeb związanych z wdrażaniem klas w przyszłym życiu/zakresie zarządzania. Celem interfejsu jest umożliwienie obiektowi wyeksponowania niektórych interfejsów API, aby mógł on być przydatny dla niektórych użytkowników. Niektóre interfejsy mogą być powiązane z zarządzaniem na całe życie (np. IDisposable), ale ich łączenie z interfejsami niezwiązanymi z zarządzaniem na całe życie może spowodować, że pisanie implementacji interfejsu będzie trudne lub niemożliwe. Jeśli masz bardzo mało implementacji interfejsu i struktury kodu, aby konsument interfejsu i menedżer życia/zakresu były w tej samej metodzie, to rozróżnienie to nie jest jasne na początku. Ale jeśli zaczniesz omijać swój obiekt, będzie to wyraźniejsze.

W powyższym przykładzie kodu pokazałem trzy typy scenariuszy zarządzania na całe życie, dodając do dwóch podanych przez Ciebie.

1. SampleA jest IDisposable synchronicznego using() {} nośniku.
2. SampleB używa czystego zbierania śmieci (nie zużywa żadnych zasobów).
3. SampleC wykorzystuje zasoby, które uniemożliwiają ich synchroniczną likwidację i wymaga pod koniec swojego życia okresu await (aby mógł powiadomić kod zarządzania na całe życie, że wykonał on zużywanie zasobów i wywoływał efekt bąbelków w przypadku wszelkich asynchronicznie występujących wyjątków).

Utrzymując zarządzania dożywotnią oddzielić od innych interfejsów, można uniknąć błędów programistów (np przypadkowych połączeń do Dispose()) i bardziej czysto wspierać przyszłych nieoczekiwanych wzorców zarządzania życia/zakres.