問題タブ [explicit-interface]

現在 IDictionary<> を拡張するインターフェース (および Dictionary<> を拡張する実装) がありますが、エントリの追加または削除を許可しないこのインターフェースの実装が必要です (既存のエントリを変わったけど）。ReadOnlyCollection アプローチを採用して NotSupportedException をスローすることもできますが、これは少し間違っているように感じます。

代わりに、インターフェイスを分割して、アクセサー ビット用に 1 つ、ミューテーター ビット用に 1 つ用意しました。これを行うために、次のような結果になったことを除いて、これはすべて問題ありません（簡潔にするためにほとんどのメソッドを削除しました）：

そして、私の元のインターフェースは次のようになりました。

そして、次のように定義された実装クラス:

と のインデクサー間のあいまいさを避けるために、インデクサーを新しくする必要がIDictionaryありIAccessorました。ただし、実際の問題は、上のセッター インデクサーの動作がDictionary辞書に新しいエントリを作成することです。インターフェイスでエントリの変更のみを許可し、作成は許可しないようにしたいのでIAccessor、の実装で何をすべきAttributeDictionaryですか? 指定されたキーが辞書にあることを最初にチェックし、そうでない場合は例外をスローするインデクサーメソッドを明示的に実装する必要がIAccessorありますか、または異なる動作を持つ2つのインデクサーを持つことは悪い考えですか? IAccessorそれとも、インターフェイスのインデクサーを捨てて、代わりにGetValueandSetValueメソッドを使用して混乱を避けるべきですか?

SOに関する Q&A はたくさんありますがIDisposable、私はまだこれに対する答えを見つけていません。

私は通常、クラスの 1 つがIDisposableオブジェクトを所有している場合、所有しているオブジェクトも実装IDisposableして呼び出すという慣行に従いDisposeます。IDisposableしかし最近、明示的に実装されたクラスに出くわしたため、直接呼び出しDisposeて強制的にキャストすることができず、迷惑で不要であることがわかりました。

では、質問: の明示的なインターフェイス実装を使用する理由と時期はIDisposable? インターフェイスを明示的に実装するための完全に適切で正当な理由があることは知っていますが、IDisposableその理由に関しては私にははっきりしていません。

私の質問はこれに多少関連しています:ジェネリック制約は、暗黙的に実装されたインターフェイスを使用した値型のボックス化をどのように防止しますか? 、しかし、これはまったく一般的ではないため、これを行うために制約を必要としないため、異なります。

私はコードを持っています

main メソッドは次のようにコンパイルされます。

なぜこれにコンパイルされないのですか？

仮想呼び出しを行うためにメソッド テーブルが必要な理由はわかりますが、この場合は仮想呼び出しを行う必要はありません。インターフェイスが正常に実装されている場合、仮想呼び出しは行われません。

関連:明示的なインターフェイスの実装がプライベートなのはなぜですか? - この質問に対する既存の回答では、メソッドがメタデータで非公開としてマークされている理由を適切に説明していません (単に使用できない名前を持つのではなく)。しかし、これでもボックス化されている理由を完全には説明できません。なぜなら、C の内部から呼び出されたときにまだボックス化されているからです。

コード：

私の推測は次のとおりです。

確信はないけど。ECMA ガイドは区別に役立たなかったので、私の推測が正しいという保証を探しているのだと思います。

IXmlSerializable不変クラスに実装しています。クラスを不変に保つために、メソッドを非表示にするためにインターフェイスを明示的に実装し、ReadXml()メソッドをカプセル化してReadXml(XmlReader reader)代わりにクラスの新しいインスタンスを返す静的メソッドを使用しています。ただし、クラスが呼び出されたと仮定すると、ClassA実装を余儀なくされている方法はIXmlSerializable、ステートメントが

((ClassA)((IXmlSerializable)(ClassAObject)).ReadXml(reader))

内部ではClassAObject、IXmlSerializable.ReadXml既に作成されたオブジェクトのパラメーターに割り当てています。ということは、ClassAObjectまだ不変と見なすことができますか？

特定のメソッドまたはプロパティが特定のインターフェイスから取得され、明示的に実装されているかどうかを判断できる必要があります。
誰かがこれを行ったことがありますか?実際に.NETリフレクションを使用してこの情報を取得することは可能ですか?

アップデート

受け入れられた回答の下のコメントに見られるように、私が実際に達成しようとしているのは、リフレクションを介して特定のインターフェイスを実装するメソッドを呼び出すことです。同じメソッド シグネチャを持つ複数のインターフェイスを持つ可能性があるため、インターフェイスに基づいて呼び出す適切な実装を決定したいと考えました。私のシナリオでは、実装タイプ、インターフェース、およびメソッド名は実行時に決定されるため、私の場合は単純なキャストを使用できません。

読み取り専用コレクションのコードを見ると、「Add」メソッドはありませんが、代わりにICollection<T>.Add(T Value)メソッドを定義しています（明示的なインターフェイスの実装）。

ReadOnlyDictionaryクラスで同様のことをしたとき、 FxCop10はCA1033を壊していると文句を言います。

ReadOnlyCollectionClass：

それで、これは誤検知ですか？Microsoftのベースコードは悪いですか？何が得られますか？

コンパイラの警告が表示されます：Type parameter 'T' has the same name as the type parameter from outer type '...'

私はやってみました：void IFoobar.Foo<U>(int x) { Foo(x); }しかし、UとTが同じであることを保証することはできません。Foobarクラスの実装方法は、同じであることが非常に重要です。

また、次のことも試してみました。void IFoobar.Foo<U>(int x) where U : T { Foo(x); }ただし、UとTが等しいことを保証するものではなく、インターフェイスで定義されているため、制約を再定義することはできません。

記録のために、私はすでにこの接続アイテムを見ましたが、これをサポートする上で何が問題になるのか本当に理解できません。

次のコードがあるとします。

仮想識別子の問題は何ですか？仮想モディファイアがあるとoverride、基本クラスに別の実装があることを示すことができます。仮想メソッドを削除し、次のような派生クラスを作成することで、これを機能させることができます。

ただし、この方法では、何かをオーバーライドしていることをまったく示していません。

更新：
C＃（パート：20.4.1明示的なインターフェイスメンバーの実装）仕様によると、2つの理由があります。

1. 特定のメソッドの非表示（私はそれを使用しています）。
2. シグニチャは同じでリターンタイプが異なる2つの関数があります（たとえば、IClonableに役立ちます）。

ただし、これらのメソッドを仮想化できない理由については何も述べていません。

Update2：
答えを考えると、ここで本当の質問を言い換えるべきだと思います。上記の2つの理由が、そもそもインターフェースの明示的な実装が可能になった理由である場合。メソッドを仮想化すると、なぜ問題になるのでしょうか。

先日、C# Boolean 構造体のメタデータを見ていました。

Boolean はインターフェイス IConvertible を実装します。しかし、Boolean のメンバーを見ると、ほとんどの IConvertible メンバーが見えませんでした。

独自のクラスを作成するなど、何人かの同僚といくつかのテストを行い、IConvertible を Boolean 用に明示的に実装する必要があるという結論に達しました。

問題は、なぜそれらが表示されないのかということです。「設計上の決定」である可能性があることは理解していますが、メタデータを検査しているすべての人に表示されると、より大きな価値が追加されることを理解しています.

テストは VS2010 .NET4.0 で行われました