Допустимо ли использовать явную реализацию интерфейса для скрытия членов в 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 может отличаться. На самом деле не лучший способ решить эту проблему, за исключением явных интерфейсов. Альтернативой является запрещение реализации перекрывающихся интерфейсов или объявление о том, что интерфейсы не могут ассоциировать семантику (что в любом случае является просто концептуальной вещью). Оба - плохие альтернативы. Иногда практичность превосходит элегантность.

Некоторые авторы / эксперты считают это существом (методы на самом деле не являются частью объектной модели типа). Но, как и все функции, где-то кому-то это нужно

Опять же, я бы не стал использовать это для сокрытия или организации. Есть способы скрыть участников от intellisense.

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

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

IE ReadOnlyCollection реализует IList <T>. Смотрите также мой вопрос к SO несколько лет назад, когда я обдумывал это.

Это хорошо, когда член бессмыслен в контексте. Например, если вы создаете коллекцию только для чтения, которая реализуется 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атрибута, чтобы скрыть член от intellisense, хотя даже это было бы утомительно; У людей уже есть свое программное обеспечение для фильтрации того, что им не интересно.