Alex Rivera | Logout

What is "Best Practice" For Comparing Two Instances of a Reference Type?

Asked 2008-09-19T18:07:02.760
49

I came across this recently, up until now I have been happily overriding the equality operator (==) and/or Equals method in order to see if two references types actually contained the same data (i.e. two different instances that look the same).

I have been using this even more since I have been getting more in to automated testing (comparing reference/expected data against that returned).

While looking over some of the coding standards guidelines in MSDN I came across an article that advises against it. Now I understand why the article is saying this (because they are not the same instance) but it does not answer the question:

  1. What is the best way to compare two reference types?
  2. Should we implement IComparable? (I have also seen mention that this should be reserved for value types only).
  3. Is there some interface I don't know about?
  4. Should we just roll our own?!

Many Thanks ^_^

Update

Looks like I had mis-read some of the documentation (it's been a long day) and overriding Equals may be the way to go..

If you are implementing reference types, you should consider overriding the Equals method on a reference type if your type looks like a base type such as a Point, String, BigNumber, and so on. Most reference types should not overload the equality operator, even if they override Equals. However, if you are implementing a reference type that is intended to have value semantics, such as

c# .net comparison operator-overloading equality
Edit
Report

1 Answer

0

I believe getting something as simple as checking objects for equality correct is a bit tricky with .NET's design.

For Struct

1) Implement IEquatable<T>. It improves performance noticeably.

2) Since you're having your own Equals now, override GetHashCode, and to be consistent with various equality checking override object.Equals as well.

3) Overloading == and != operators need not be religiously done since the compiler will warn if you unintentionally equate a struct with another with a == or !=, but its good to do so to be consistent with Equals methods.

public struct Entity : IEquatable<Entity>
{
    public bool Equals(Entity other)
    {
        throw new NotImplementedException("Your equality check here...");
    }

    public override bool Equals(object obj)
    {
        if (obj == null || !(obj is Entity))
            return false;

        return Equals((Entity)obj);
    }

    public static bool operator ==(Entity e1, Entity e2)
    {
        return e1.Equals(e2);
    }

    public static bool operator !=(Entity e1, Entity e2)
    {
        return !(e1 == e2);
    }

    public override int GetHashCode()
    {
        throw new NotImplementedException("Your lightweight hashing algorithm, consistent with Equals method, here...");
    }
}

For Class

From MS:

Most reference types should not overload the equality operator, even if they override Equals.

To me == feels like value equality, more like a syntactic sugar for Equals method. Writing a == b is much more intuitive than writing a.Equals(b). Rarely we'll need to check reference equality. In abstract levels dealing with logical representations of physical objects this is not so

answered 2012-12-16T20:17:47.890

Your Answer