問題タブ [explicit-interface]

より具体的には、私が持っている場合：

リフレクションを使用して、TempInterface を明示的に実装するプロパティのすべての propertyInfos を取得するにはどうすればよいですか?

ありがとう。

codeplexでASP.NET MVC ソース コードを参照しているときに、インターフェイスを明示的に実装するクラスが一般的であることがわかりました。明示的に実装されたメソッド/プロパティは、同じ名前の別の「保護された仮想」メソッド/プロパティを呼び出します。

例えば、

私は今、この種のプログラミングの利点が何であるかを確信しています。私にとっては、インターフェイス IHttpHandler を暗黙的に実装することを好みます。

作成者は、 MvcHandlerにパブリック プロパティIsResuableを持たせたくないだけだと思います。プロパティIsReusableは、 MvcHandlerのインスタンスがIHttpHandlerとして扱われる場合にのみ使用できます。それでも、なぜ作者がこのようにしたのかはわかりません。

このスタイルのインターフェイス実装の利点を知っている人はいますか?

明示的なメンバー実装の現在のガイドラインでは、次のことを推奨しています。

• 明示的なメンバーを使用して、プライベートインターフェイスの実装を概算します。インフラストラクチャの理由のみでインターフェイスを実装する必要があり、開発者がこのタイプからそのインターフェイスのメソッドを直接呼び出すことを期待しない場合は、メンバーを明示的に実装して、パブリックビューからそれらを「非表示」にします。
• サブクラスがオーバーライドを許可されている明示的に実装されたメンバーにアクセスするための代替方法を公開します。

この良い例は、IXmlSerializableインターフェースを実装する場合です。ReadXmlメソッドとWriteXmlメソッドは、XmlSerializerによって呼び出されることが期待されており、通常、開発者によって直接呼び出されることはありません。

オーバーライドを許可したいメンバーに明示的にアクセスする別の方法を提供する場合、コードの重複を避けるために、明示的に実装されたメンバーを呼び出すことは理にかなっているようです。次のことを考慮してください。

私の質問は、この実装でのWriteXmlメソッドのボクシングのコストに関するものです。（（ IXmlSerializable ）this）.WriteXml（writer）は、パフォーマンスを大幅に低下させますか？

ICollection(T)インターフェイスの Add メソッドは、 LinkedList(T)クラスによって明示的に実装されています。このコレクションには、代わりに AddFirst メソッドと AddLast メソッドがあります (特に)。明示的に実装されたメソッドは、AddLast メソッドにマップされます。これにはいくつかの欠点があり、IMHO にはまったくメリットがありません。2つの主な欠点は次のとおりです。

1. Add メソッドが必要なため、LinkedList(T) でコレクションの初期化を使用することはできません。
2. メソッドで List(T) を使用していて、代わりに LinkedList(T) を使用するように変更したい場合は、代わりに AddLast を呼び出すように Add へのすべての呼び出しを更新する必要があります。

私が考える方法は、具象型を知っているときにまったく意味がない場合を除き、インターフェイス メンバーを明示的に実装するべきではないということです。たとえば、読み取り専用の ICollection(T) を実装している場合は、Add メソッドを明示的に実装する (そして効果的に非表示にする) 必要があります。

フレームワークに含めるべきではない、明示的に実装されたメソッドの他の例はありますか?

補足: 2 番目の問題を解決するには、LinkedList(T) クラスの拡張メソッド「Add」を作成します。

文字列型のプロパティを実装する型があるとします。

次に、同じ名前のプロパティを定義するインターフェイスがあります。

次のように明示的なインターフェイスを使用できます。

ただし、明示的なインターフェイスで文字列「Value」を参照できるようにしたい場合は、できますか? もしそうなら、どのように？私はそれが次のようなものだと想像します：

ご覧のとおり、「int 値」「Value」プロパティの式に「文字列値」「Value」プロパティが必要です。それが別の明示的に実装されたインターフェイス メンバーである場合、そのインターフェイスに型キャストしてから使用できますが、暗黙の型メンバーに対してはどのように機能するのでしょうか?

注: この例は少し不自然ですが、うまくいけば言語の問題を示しています。

IListと の両方を実装する C++/CLI クラスを実装しようとしていますIList<T>。

名前が重複しているため、そのうちの 1 つを明示的に実装する必要があり、当然の選択として IList を選択する必要があります。

インデクサーの暗黙的な実装は次のとおりです。

現在、IList の既定のインデクサーを宣言しようとしています。

私の推測では、次のようになります。

しかし、それは私に与えます

エラー C2061: 構文エラー: 識別子 'デフォルト'

ヒントはありますか？

コード：

エラー：

[Bar] に 'Foo' という名前のメソッドが含まれていないため、メソッドの呼び出しに失敗しました。

次のプロパティからコンパイル エラーが発生します。
エラーは次のとおりです。

「修飾子 'public' はこのアイテムには無効です」

しかし、削除するIWorkItemControlと正常にコンパイルされます。

このエラーが発生するのはなぜですか? また、署名にインターフェイス名がある場合とない場合の違いは何ですか?

以前は気付かなかった C# メソッド解決の機能に出くわしました。つまり、セッターをサポートするインターフェイスを明示的に実装し、暗黙的なインターフェイスが保護されたセットのみを提供する場合、コンパイラーは保護されたセットを呼び出すときに賢明に延期します。したがって、自動実装されたプロパティの利便性を最大限に活用できますが、フィールドを変更してはならないクライアントによるフィールドの偶発的な変更を防ぐことができます。

例として、

次に、モデル バインディング コードが誤って日付を設定することはありませんが、ORM イベント リスナーは IHaveUpdateDateFields を実装するエンティティをチェックし、エンティティを永続化するときに日付を設定できます。

私の質問は次のとおりです。

1. 定義された動作に依存していますか?それとも、すべての C# コンパイラがこの方法でメソッドを解決することが保証されていますか? C# の標準では、この種のメソッド解決は未定義であり、Mono 用にビルドするときに誤って恐ろしいスタック オーバーフローが発生することを発見したくありません。
2. これを行うためのより良い（理想的には簡潔な）方法はありますか？コントローラーに渡す ModelBinder セーフ インターフェイスを使用することもできますが、それによってコードが節約されるとは思えず、プロパティの偶発的な変更を最小限に抑えるための透過的なアプローチが提供されるとは思えません。

出力:
B->こんにちは! 明示的から。

そうではありませんか？
A→こんにちは！明示的から。

明示的なキャスト (IHello) がクラス A から IHello.Hello() を呼び出さないのはなぜですか?