IEquatable<T>
インターフェイスを使用して比較したいオブジェクトを実装する場合:
Equals(object)
既に実装している場合、メソッドをオーバーライドする必要があるのはなぜEquals(T)
ですか?==
実装したらand!=
演算子を使用できますIEquatable<T>
か?
IEquatable<T>
インターフェイスを使用して比較したいオブジェクトを実装する場合:
Equals(object)
既に実装している場合、メソッドをオーバーライドする必要があるのはなぜEquals(T)
ですか?==
実装したらand!=
演算子を使用できますIEquatable<T>
か?を実装する場合は、と
IEquatable<T>
の基本クラスの実装もオーバーライドし て、その動作が メソッドの動作と一致するようにする必要があります。override を 実行すると、オーバーライドされた実装も クラスの静的メソッドの呼び出しで呼び出されます。さらに、 and演算子をオーバーロードする必要があります。これにより、等しいかどうかのすべてのテストで一貫した結果が返されることが保証されます。Equals(Object)
GetHashCode()
Equals(T)
Equals(Object)
Equals(Object, Object)
op_Equality
op_Inequality
いいえ、演算子は Equals メソッドを使用しません。そのためには、個別にオーバーロードする必要があります。
Equals(object)
1) レイが言ったように、実装することを (静的に) 知らないクラスからメソッドが呼び出されたときに一貫性を確保するためにオーバーライドしますIEquatable<T>
。たとえば、非ジェネリック コレクション クラスはEquals(object)
比較に使用します。もオーバーライドする必要がありますGetHashCode()
。
2) 実装IEquatable<T>
によって == および != 演算子が自動的にオーバーロードされることはありませんが、そうするのを止めるものは何もありSystem.String
ません。ただし、これを行う場合は、これを非常に明確に文書化する必要があります。また、同一性比較を引き続き使用する他のタイプの参照 (MyType と Object など) を比較する場合は注意してください。これを行うのは良い考えではないと思いますが、それがコードで非常に頻繁に使用される型であり、誰もがそれに慣れ親しみ、オーバーロード == の構文糖衣が読みやすさに本当にプラスの影響を与える場合を除きます。