Some common misconceptions about the Equals method in C # beginners

Many C # Textbooks will emphasize the concept of object equality. As we all know, there are two kinds of equivalence in the C # world. One is logical equivalence: if two objects logically represent the same value, they are said to have logical equivalence. The other is referential equivalence: If two references point to the same object instance, they are said to have referential equivalence.

As we all know, the object type has an instance method named Equals that can be used to determine whether two objects are equal. The default implementation of equals of object compares the reference equivalence of two objects. The derived class of object, Valuetpye, overrides the Equals method, which compares the logical equivalence of two objects. That is, in C #, the default equals version of a reference type is concerned with referential equivalence, while value types are concerned with logical equivalence. Of course, this does not always meet our requirements. So whenever we care more about the logical equivalence of reference types, we should rewrite the Equals method.

A notable example of overriding a reference type's Equals method to change its default comparison is the String class. When we write string1. In the case of Equals (string2), we compare whether the two references to string1 and string2 refer to the same instance (referential equivalence), but rather whether the string1 and string2 contain the same sequence of characters (logical equivalence).

Myth One: The Equals method and operator== have the same default behavior.

For reference types, if the = = operator is not overloaded for it and its parent type does not override the Equals method, then the Equals method and operator== have the same default behavior, that is, they compare the reference equivalence of the object. However, for value types, this is not the case at all! Because if you do not overload operator== for a custom value type, you cannot write code MyStruct1 = = MyStruct2, or you will get a compilation error because the value type does not have a default implementation of the equality operator overload.

Myth Two: Method of the Equals of the custom class the default implementation will automatically call the operator== method, or the default implementation of the operator== method will automatically call the Equals method.

Often you hear someone say that a type is a reference type, so its default implementation of the Equals method will automatically call the operator== method. There is absolutely no justification for this argument. As mentioned above, the default implementation of the Equals method of the reference type comes from object, and the default implementation of the value type comes from typevalue, even if they use the = = operator, which is an overloaded version of object or Typevalue. In principle, as long as we do not rewrite the Equals method of a class, it inherits the implementation of its parent class, and the parent class is not given the opportunity to use the operator overloads of the subtype. Similarly, it is not automatically invoked as long as we do not invoke the Equals method in the = = operator overload of a class.

Myth Three: The default equals implementation of a value type is a bitwise comparison of two objects.

Some people think that the equals default implementation of a value type is by comparing the bits represented by two objects in memory, that is, if all bits are equal, then the two objects are equivalent. This is not accurate. Because the equals default implementation of a value type is the Equals method that calls the field type for each field of the value type, they may be equal if all the Equals methods of the field return true. Take a look at an example:

The     equals method of class myclass{public override bool Equals (object obj)    {        Console.WriteLine ("MyClass" is called. ");        return true;    }} struct mystruct{public     MyClass Filed;} Class program{     staticvoid Main (string[] args)     {         mystruct A;         MyStruct b;         a.filed = new MyClass ();         b.filed = new MyClass ();         Console.WriteLine (A.equals (b));      ｝

Clearly, A and B have completely different bits representations. But the result of the final printing is:

The Equals method of the MyClass is called.

True

This indicates that the default implementation of a value type is determined by calling the Equals method of the field to determine whether two objects are equal, rather than by comparing whether their bits are consistent.

Myth four: Equals is a very basic, very common method, so there is no performance problem with its default implementation.

For reference types, the default implementation of equals is simple, just to determine whether two references are the same type, two references to the same block of memory. So there's no problem with its performance. For value types, however, the task for equals is less straightforward. It requires a comparison of all the fields of two objects, that is, the Equals of the field type called verbatim. Because in ValueType (where the value type Equals method is implemented by default), it is not possible to know which fields are included in all of its subtypes, so in order to invoke the Equals method of the Subtype field, the Equals of ValueType needs to use the reflection technique. As you may have seen, reflection is not a performance-friendly technique, so the Equals method of a value type is not efficient. This is why Microsoft recommends that we override the Equals method for custom value types.