Чи дозволено використовувати явну реалізацію інтерфейсу, щоб приховати членів у C #?

Я розумію, як працювати з інтерфейсами та явною реалізацією інтерфейсу в C #, але мені було цікаво, чи вважається поганою формою приховування певних членів, які не використовуються часто. Наприклад:

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

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

Я знаю заздалегідь, що події, хоча й корисні, дуже рідко використовуються. Таким чином, я вважав, що має сенс сховати їх від класу впровадження шляхом явної реалізації, щоб уникнути безладу IntelliSense.

Так, це взагалі погана форма.

Таким чином, я вважав, що має сенс сховати їх від класу впровадження шляхом явної реалізації, щоб уникнути безладу IntelliSense.

Якщо ваш IntelliSense занадто захаращений, ваш клас занадто великий. Якщо ваш клас занадто великий, він, ймовірно, робить занадто багато речей і / або погано розроблений.

Виправте свою проблему, а не ваш симптом.

Використовуйте функцію для того, для чого вона призначена. Зменшення захаращення простору імен - не одне з таких.

Законні причини не полягають у тому, щоб "ховатися" чи організуватись, вони повинні вирішити неоднозначність та спеціалізуватися. Якщо ви реалізуєте два інтерфейси, які визначають "Foo", семантика для Foo може відрізнятися. Дійсно, не кращий спосіб вирішити це питання, крім явних інтерфейсів. Альтернатива - забороняти реалізовувати інтерфейси, що перекриваються, або заявляти, що інтерфейси не можуть пов'язувати семантику (що все одно просто концептуальна річ). Обидва є поганими альтернативами. Іноді практичність козиряє елегантністю.

Деякі автори / експерти вважають це зграєю функції (методи насправді не є частиною об'єктної моделі типу). Але як і всі функції, десь комусь це потрібно.

Знову ж таки, я б не використовував це для приховування чи організації. Є способи приховати членів від інтелігенції.

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

Я можу бути ознакою безладного коду, але іноді реальний світ безладний. Одним із прикладів .NET Framework є ReadOnlyColection, який приховує мутаційний сетер [], Add and Set.

IE ReadOnlyCollection реалізує IList <T>. Дивіться також моє запитання до ТА кілька років тому, коли я розмірковував над цим.

Добре це робити, коли член безглуздий у контексті. Наприклад, якщо ви створюєте колекцію для читання тільки, яка реалізується IList<T>шляхом делегування до внутрішнього об'єкта, у _wrappedвас може виникнути щось на зразок:

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

Тут у нас є чотири різні випадки.

public T this[int index]визначається нашим класом, а не інтерфейсом, і, отже, це, звичайно, не явна реалізація, хоча зауважте, що це, схоже, T this[int index]визначено в інтерфейсі читання-запису, але лише для читання.

T IList<T>.this[int index]є явним, тому що одна його частина (гетьтер) ідеально відповідає властивості, наведеній вище, а інша частина завжди буде винятком винятку. Хоча життєво важливим є той, хто звертається до екземпляра цього класу через інтерфейс, але безглуздо для того, щоб хтось використовував його через змінну типу класу.

Аналогічно тому bool ICollection<T>.IsReadOnly, що завжди повертається true, коди, написані проти типу класу, абсолютно безглуздо, але це може бути життєво важливим для цього, використовуючи його через тип інтерфейсу, і тому ми явно реалізуємо це.

І навпаки, public int Countвона не реалізується явно, оскільки потенційно може бути корисною для того, хто використовує екземпляр через власний тип.

Але у вашому випадку "дуже рідко використовується" я б дуже сильно схилявся до того, щоб не використовувати явну реалізацію.

У тих випадках, коли я рекомендую використовувати явну реалізацію, виклик методу через змінну типу класу буде або помилкою (спроба використання індексованого сеттера), або безглуздою (перевірка значення, яке завжди буде однаковим), так що приховується ними ви захищаєте користувача від баггі чи неоптимального коду. Це суттєво відрізняється від коду, який, на вашу думку, просто, ймовірно, використовується рідко . З цього приводу я міг би скористатися EditorBrowsableатрибутом, щоб приховати член від інтелігенції, хоча навіть від цього я б втомлювався; мозок людей вже має власне програмне забезпечення для фільтрації того, що їх не цікавить.