Analiza Kod CA1063 pożary, gdy wynikające z IDisposable i zapewniające realizację w klasie bazowej

Question

mam jakiś kod, który wyzwoli CA1063 Code Analysis Ostrzeżenie:

CA1063: Microsoft.Design: IDisposable Usuń z listy interfejsów realizowanych przez "Funkcjonalność" i nadpisanie klasy bazowej Zamiast tego należy użyć implementacji.

Jednak nie jestem pewien, co muszę zrobić, aby naprawić to ostrzeżenie.

Krótko, mam interfejs IFunctionality, który pochodzi od IDisposable. Klasa Functionality implementuje IFunctionality, ale wywodzi się z klasy Reusable, aby móc ponownie użyć som-kodu. Klasa Reusable również pochodzi z IDisposable.

public class Reusable : IDisposable { 

    ~Reusable() { 
    Dispose(false); 
    } 

    public void Dispose() { 
    Dispose(true); 
    GC.SuppressFinalize(this); 
    } 

    protected virtual void Dispose(Boolean disposing) { 
    // ... 
    } 

    public void DoSomething() { 
    // ... 
    } 

} 

public interface IFunctionality : IDisposable { 

    void DoSomething(); 

    void DoSomethingElse(); 

} 

public class Functionality : Reusable, IFunctionality { 

    public void DoSomethingElse() { 
    // ... 
    } 

#if WORK_AROUND_CA1063 
    // Removes CA1063 
    protected override void Dispose(Boolean disposing) { 
    base.Dispose(disposing); 
    } 
#endif 

} 

mogę pozbyć się ostrzeżenia nadrzędnymi Dispose na Functionality i wywołanie klasy podstawowej Dispose choć robi to nie powinno zmienić semantykę kodu.

Więc czy jest coś o IDisposable w tym kontekście przeoczyłem, czy jest to po prostu CA1063, który wypala dla tego konkretnego konstruktu?

Wiem, że mogę stłumić CA1063, ale zasada jest dość szeroka i nie chcę przegapić żadnych innych problemów związanych z wdrażaniem IDisposable zgłoszonych przez tę regułę.

Answer 1

Jest to wynik fałszywie dodatni z powodu drobnego błędu samej reguły. Podczas próby ustalenia, czy klasa ponownie implementuje IDisposable (po ustaleniu, że istnieje implementacja klasy podstawowej, którą można przesłonić), sprawdza tylko, czy interfejsy klasy zawierają IDisposable. Niestety, lista interfejsów wyświetlana w metadanych zestawu zawiera listę "rozstrzelonych" interfejsów, w tym wszelkie interfejsy odziedziczone za pośrednictwem interfejsów, które klasa jawnie implementuje w oryginalnym kodzie C#.Oznacza to, że FxCop widzi deklarację, która wygląda jak poniżej na swojej klasie funkcjonalność:

public class Functionality : Reusable, IFunctionality, IDisposable 
{ 
    ... 
} 

Given to reprezentacja metadane, reguła ImplementIDisposableCorrectly powinien być nieco bardziej inteligentny, jak to stara się ustalić, czy klasa jest rzeczywiście ponowne wdrożenie IDisposable (na przykład, patrząc na jawną implementację Dispose(), jeśli klasa bazowa ma opcję overridable Dispose (bool)). Jednak, zważywszy, że reguła tego nie robi, najlepszym wyjściem jest stłumienie fałszywych alarmów.

BTW, polecam poważnie biorąc pod uwagę użycie SuppressMessageAttribute do tłumienia fałszywych alarmów zamiast aktualnej metody kompilacji warunkowej. np .:

[SuppressMessage("Microsoft.Design", "CA1063:ImplementIDisposableCorrectly", 
    Justification = "False positive. IDisposable is inherited via IFunctionality. See http://stackoverflow.com/questions/8925925/code-analysis-ca1063-fires-when-deriving-from-idisposable-and-providing-implemen for details.")] 
public class Functionality : Reusable, IFunctionality 
{ 
    ... 
} 

Ponadto, warto poważnie rozważyć getting rid of the finalizer ...

Answer 2

Jest to związane z korzystaniem z IDisposable, a nie z samego interfejsu. Po prostu implementujesz zalecany wzorzec do jego używania, dostarczając i zastępując chronioną metodę Dispose(bool) - nie jest to część samego interfejsu.

Jeśli twoja metoda zastąpienia nie dodaje niczego, to nie ma problemu z pominięciem go. Ostrzeżenie CA1063 ma na celu uwydatnienie tego problemu, ale jeśli wiesz, że w rzeczywistości nie ma żadnych zasobów do rozwiązania, możesz go obejść, podając pustą implementację, lub wyłączając tę ​​konkretną regułę dla tego konkretnego przypadku. plik.

Możesz to zrobić za pomocą atrybutu [SuppressMessage].

Answer 3

Twoje "obejście" jest tutaj właściwym wzorcem dla klasy pochodnej, która ponownie implementuje IDisposable.

Ale myślę, że powinieneś ponownie rozważyć projekt IFunctionality : IDisposable. Czy bycie jednorazowym naprawdę jest problemem o numerze IFunctionality? Myślę, że ta decyzja należy do klasy wykonawczej.