Czy dozwolone jest używanie jawnej implementacji interfejsu do ukrywania członków w C #?

Rozumiem, jak pracować z interfejsami i implementacją jawnego interfejsu w języku C #, ale zastanawiałem się, czy ukrywanie niektórych elementów, które nie byłyby często używane, jest złym rozwiązaniem. Na przykład:

public interface IMyInterface
{
    int SomeValue { get; set; }
    int AnotherValue { get; set; }
    bool SomeFlag { get; set; }

    event EventHandler SomeValueChanged;
    event EventHandler AnotherValueChanged;
    event EventHandler SomeFlagChanged;
}

Wiem z góry, że wydarzenia, choć przydatne, bardzo rzadko byłyby wykorzystywane. Pomyślałem więc, że warto ukryć je przed klasą implementacyjną poprzez jawną implementację, aby uniknąć bałaganu IntelliSense.

Tak, ogólnie jest to zła forma.

Pomyślałem więc, że warto ukryć je przed klasą implementacyjną poprzez jawną implementację, aby uniknąć bałaganu IntelliSense.

Jeśli twój IntelliSense jest zbyt zagracony, twoja klasa jest za duża. Jeśli twoja klasa jest zbyt duża, prawdopodobnie robi zbyt wiele rzeczy i / lub źle zaprojektowana.

Napraw swój problem, a nie objaw.

Użyj funkcji do tego, do czego była przeznaczona. Ograniczanie bałaganu przestrzeni nazw nie jest jednym z nich.

Uzasadnione powody nie polegają na „ukrywaniu się” i organizowaniu, lecz na rozwiązywaniu niejednoznaczności i specjalizacji. Jeśli zaimplementujesz dwa interfejsy definiujące „Foo”, semantyka dla Foo może się różnić. Naprawdę nie jest to lepszy sposób na rozwiązanie tego, z wyjątkiem jawnych interfejsów. Alternatywą jest uniemożliwienie implementacji nakładających się interfejsów lub zadeklarowanie, że interfejsy nie mogą powiązać semantyki (co zresztą jest po prostu kwestią konceptualną). Obie są słabymi alternatywami. Czasami praktyczność przebija elegancję.

Niektórzy autorzy / eksperci uważają to za kłopot funkcji (metody nie są tak naprawdę częścią modelu obiektowego typu). Ale podobnie jak wszystkie funkcje, ktoś go potrzebuje.

Ponownie nie użyłbym tego do ukrywania się lub organizacji. Istnieją sposoby na ukrycie członków przed intellisense.

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Mogę być oznaką niechlujnego kodu, ale czasami prawdziwy świat jest bałagan. Jednym z przykładów .NET Framework jest ReadOnlyColection, który ukrywa ustawiającą mutację [], Dodaj i Ustaw.

IE ReadOnlyCollection implementuje IList <T>. Zobacz także moje pytanie do SO kilka lat temu, kiedy się nad tym zastanawiałem.

Jest to dobra forma, aby zrobić to, gdy członek jest bezcelowy w kontekście. Na przykład, jeśli utworzysz kolekcję tylko do odczytu, która implementuje się IList<T>przez delegowanie do obiektu wewnętrznego, _wrappedmożesz mieć coś takiego:

public T this[int index]
{
  get
  {
     return _wrapped[index];
  }
}
T IList<T>.this[int index]
{
  get
  {
    return this[index];
  }
  set
  {
    throw new NotSupportedException("Collection is read-only.");
  }
}
public int Count
{
  get { return _wrapped.Count; }
}
bool ICollection<T>.IsReadOnly
{
  get
  {
    return true;
  }
}

Tutaj mamy cztery różne przypadki.

public T this[int index]jest zdefiniowany przez naszą klasę, a nie przez interfejs, a zatem nie jest oczywiście jawną implementacją, choć zauważ, że jest podobny do odczytu-zapisu T this[int index]zdefiniowanego w interfejsie, ale jest tylko do odczytu.

T IList<T>.this[int index]jest jawny, ponieważ jedna jego część (getter) jest idealnie dopasowana do powyższej właściwości, a druga część zawsze zgłasza wyjątek. Chociaż jest to niezbędne dla kogoś, kto uzyskuje dostęp do instancji tej klasy za pośrednictwem interfejsu, nie ma sensu, aby ktoś używał jej za pośrednictwem zmiennej typu klasy.

Podobnie, ponieważ bool ICollection<T>.IsReadOnlyzawsze będzie zwracać wartość true, absolutnie bezcelowe jest pisanie kodu przeciw typowi klasy, ale może mieć to zasadnicze znaczenie przy używaniu go przez typ interfejsu, dlatego też implementujemy go jawnie.

I odwrotnie, public int Countnie jest jawnie zaimplementowany, ponieważ może potencjalnie być użyteczny dla kogoś, kto korzysta z instancji za pośrednictwem własnego typu.

Ale w twoim przypadku „bardzo rzadko używanym” bardzo mocno skłaniałbym się ku nieużywaniu wyraźnej implementacji.

W przypadkach, w których zalecam użycie jawnej implementacji wywołanie metody przez zmienną typu klasy byłoby albo błędem (próba użycia indeksowanego setera), albo bezcelowym (sprawdzenie wartości, która zawsze będzie taka sama), więc ukrywanie chronisz użytkownika przed błędnym lub nieoptymalnym kodem. To znacznie różni się od kodu, który Twoim zdaniem jest rzadko używany. W tym celu mógłbym rozważyć użycie tego EditorBrowsableatrybutu, aby ukryć członka przed inteligencją, choć i tak byłbym zmęczony; mózgi ludzi mają już własne oprogramowanie do filtrowania tego, co ich nie interesuje.