8

私の（単体）テストカバレッジはまだかなり低いので、残念ながら、私は多くのエラーを難しい方法で見つけなければなりません。したがって、リファクタリング中は、C＃コンパイラの型チェックに大きく依存しています。

今日、リファクタリング中に発生したバグを修正しましたx.Equals(aThingWrappingOriginalThing)。それがそうであるようbool Equals(object T)に、コンパイラは文句を言いませんでした。ただし、（BCLを介してではなく）直接使用する時間の90％はEquals()、同じタイプのオブジェクトを論理的に比較することを目的としています。

今、私はなぜ誰かがEquals()そのような状況（C＃で）のタイプセーフバージョンを宣伝しているのを見たことがないのか疑問に思っています。このためのベストプラクティスはありますか？

次のように、これらの比較に拡張メソッドを使用したいと思います。

public static bool SafeEquals<T>(this T a, T b)
{
    if (a == null) return b == null;
    return a.Equals(b);
}
public static bool SafeEquals<X>(this IEquatable<X> a, IEquatable<X> b)
{
    if (a == null) return b == null;
    return a.Equals(b);
}

これらを最適化できますか？

これが私が見つけたJavaのトピックに関する唯一のブログ投稿です：http： //rickyclarkson.blogspot.com/2006/12/making-equalsobject-type-safe.html

4

2 に答える 2

5

あなたは探している

EqualityComparer<T>.Default.Equals(x,y);

これはIEquatable<T>（実装されている場合）サポートし、そうでない場合はボクシングの可能性を使用しEquals(object)ます。クラスと構造体をサポートし、Nullable<T>（ボクシングなしの）サポートを含む両方の期待されるnull動作を備えています。

于 2012-07-10T20:23:15.357 に答える
2

私が見るものは私にはよく見えます。

私の2セント：nullチェックをスキップして、これを使用する方が簡単だと思います。

public static bool SafeEquals<T>(this T a, T b)
{
    return object.Equals(a, b);
}

それが意図した動作から逸脱するケースはほとんどありません。それらの1つはEquals、両方のオブジェクトが同じオブジェクトである場合にfalseを返す場合です（とにかく発生することはありません）。

参考までにobject.Equals、これが逆コンパイルされているので、何が起こるかを自分で確認できます。

public static bool Equals(object objA, object objB)
{
    return ((objA == objB) || (((objA != null) && (objB != null)) && objA.Equals(objB)));
}
于 2012-07-10T20:18:27.883 に答える