4

これは、この質問へのフォローアップです:ラムダ式が期待される MemberInfo を返さない

class Human
{
    public string name { get; set; }
}

class Man : Human
{

}

var m1 = typeof(Human).GetProperty("name");
var m2 = typeof(Man).GetProperty("name");

//m1 != m2 why?

sについても同様MethodInfoです。

Humanがインターフェースである場合とname、Humanが抽象/仮想である場合の違いが必要であることは理解できます。しかし、なぜ密閉型の場合はそうなるのでしょうか? のは正確にはnameのではありませんか?MannameHuman

明確化: Jon が言うように、彼らReflectedTypeの s は異なります。ReflectedTypein equality は、インターフェイス メンバーまたはオーバーライドされたメンバーが異なるため、それらが等しいかどうかを判断するときに便利です。しかし、上記のような単純なケースの同等性を判断するために考慮する必要はないと思います。設計チームは一貫性を保ちたかったのかもしれません。ReflectedType複数のクラスにまたがる同じメンバーの等価性を決定する際に、フレームワーク設計者がプロパティを考慮するようになった理由は何なのか疑問に思っています。

4

1 に答える 1

7

それらはReflectedTypeプロパティが異なります。

ReflectedType プロパティは、MemberInfo のこのインスタンスを取得するために使用された Type オブジェクトを取得します。この MemberInfo オブジェクトが基本クラスから継承されたメンバーを表す場合、これは DeclaringType プロパティの値と異なる場合があります。

したがって、印刷するm1.ReflectedTypeと、印刷されるはずHumanです。印刷するm2.ReflectedTypeと、印刷されるはずManです。

編集: 等値演算子がこのように実装されている理由に関して:==オブジェクト間に区別できるが「主要な」違いはない場合、何を意味するかを判断するのは常に繊細な設計上の決定です。これは、さまざまなIEqualityComparer実装を提供することが役立つ場所ですが、もちろん、オペレーター自体には機能しません。

一般に、 が true の場合、が任意のプロパティと異なることx == yは非常にまれです。フレームワークでそれが発生するケースはすぐには思いつきません。x.Fooy.Foo

于 2013-04-29T10:26:32.623 に答える