明示的なインターフェイス実装を使用して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が散らかっている場合、クラスが大きすぎます。クラスが大きすぎる場合、多すぎることや設計が不十分である可能性があります。

症状ではなく問題を修正してください。

目的に合わせて機能を使用します。名前空間の乱雑さを減らすことはそれらの1つではありません。

正当な理由は「隠蔽」や組織に関するものではなく、曖昧さを解決して専門化することです。「Foo」を定義する2つのインターフェイスを実装すると、Fooのセマンティクスが異なる場合があります。明示的なインターフェイスを除いて、これを解決するより良い方法ではありません。別の方法は、重複するインターフェイスの実装を許可しないか、インターフェイスがセマンティクスを関連付けられないことを宣言することです（これはとにかく概念的なことです）。どちらも貧弱な選択肢です。時には実用性が優雅さよりも優先されます。

一部の著者/専門家は、それを機能のごまかしと見なしています（メソッドは実際には型のオブジェクトモデルの一部ではありません）。しかし、すべての機能のように、どこかで誰かがそれを必要とします。

繰り返しますが、私はそれを隠蔽や組織化には使用しません。メンバーをインテリセンスから隠す方法があります。

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

私は厄介なコードの兆候かもしれませんが、時には現実の世界は厄介です。.NETフレームワークの1つの例は、変更セッター[]、追加および設定を隠すReadOnlyColectionです。

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

ここには、4つの異なるケースがあります。

public T this[int index]インターフェースではなくクラスによって定義されているため、もちろん明示的な実装ではありませんT this[int index]が、インターフェースで定義された読み取り/書き込みに似ていますが、読み取り専用であることに注意してください。

T IList<T>.this[int index]その一部（ゲッター）が上記のプロパティと完全に一致し、他の部分は常に例外をスローするため、明示的です。インターフェイスを介してこのクラスのインスタンスにアクセスする人にとっては重要ですが、クラスの型の変数を介してこのクラスのインスタンスを使用する人にとっては意味がありません。

同様に、bool ICollection<T>.IsReadOnly常にtrueを返すため、クラスの型に対して記述されたコードにはまったく意味がありませんが、インターフェイスの型を介してそれを使用するために不可欠である可能性があるため、明示的に実装します。

逆に、public int Count明示的に実装されていないのは、独自の型を介してインスタンスを使用しているユーザーにとって潜在的に有用である可能性があるためです。

しかし、「ごくまれにしか使用されない」場合は、明示的な実装を使用しないことに強く傾倒します。

クラスの型の変数を介してメソッドを呼び出す明示的な実装を使用することをお勧めする場合、エラー（インデックス付きセッターの使用を試みる）または無意味（常に同じ値をチェックする）になるため、非表示になりますバグのあるコードや次善のコードからユーザーを保護しています。これは、ほとんど使用されないと思われるコードとは大きく異なります。そのため、EditorBrowsable属性を使用してメンバーをインテリセンスから隠すことを検討するかもしれませんが、それでも私は疲れます。人々の脳にはすでに、興味のないものを除外するための独自のソフトウェアがあります。