C # Some common misunderstandings of the Equals Method

Many C # textbooks emphasize the concept of equal objects. We all know that there are two kinds of equivalence in the C # World. One is logical equivalence: If two objects logically represent the same value, they are called logical equivalence. The other is to reference equality: If two references point to the same object instance, they are referred to as same-sex.

As we all know, the Object type has an instance method named Equals that can be used to determine whether two objects are equal. By default, the Equals of an Object is equivalent to the two objects. The ValueTpye of the derived class of the Object overwrites the Equals method, which compares the logical equivalence of the two objects. That is to say, in C #, the default Equals version of the reference type focuses on the reference equality, while the value type focuses on the logical equality. Of course, this does not always meet our requirements. So whenever we care more about the logical equivalence of the reference type, we should rewrite the Equals method.

A famous example of rewriting the Equals method of the reference type to change its default comparison method is the String class. When we write code such as "string1.Equals (string2)", we do not compare whether the two references string1 and string2 point to the same instance (reference equality ), it compares whether the character sequences in string1 and string2 are the same (logical equivalence ).

Misunderstanding 1: The Equals method and operator = have the same default behavior.

If the = operator is not overloaded for the reference type and the Equals method is not overwritten for its parent type, the reference type Equals method and operator = have the same default behavior, that is to say, they compare the equivalence of object references. However, this is not the case for the value type! If you do not load operator = for a custom value type, you cannot write the code "myStruct1 = myStruct2". Otherwise, a compilation error is returned, the reason is that the value type does not have the default Implementation of the Equal operator overload.

Misunderstanding 2: The default Implementation of the custom Equals method will automatically call operator = method, or the default Implementation of operator = method will automatically call the Equals method.

It is often said that a certain type is a reference type, so the default implementation of its Equals method will automatically call the operator = method. This statement is totally unreasonable. As mentioned above, the default Implementation of the reference type Equals method comes from Object, while the default Implementation of the value type comes from TypeValue, even if they use the = Operator, this is also an overloaded version of Object or TypeValue. In principle, as long as we do not override the Equals method of a class, it will inherit the implementation of its parent class, and the parent class has no chance to use the operator overload of the Child type. Similarly, as long as we do not call the Equals method in the = Operator overload of a class, it will not be automatically called.

Misunderstanding 3: The default Equals Implementation of the Value Type compares two objects one by one.

Some people think that the default Implementation of the Value Type Equals is to compare the bit representation of two objects in the memory, that is, if all the binary bits are equal, the two objects are "equivalent ". This is not accurate. In fact, the default Implementation of the Value Type Equals is to call the Equals method for each field of the value type. If the Equals method of all fields returns true, they can be equal. Let's look at an example:

Class MyClass {public override bool Equals (object obj) {Console. WriteLine ("The Equals method of MyClass is called. "); Return true ;}} struct MyStruct {public MyClass Filed;} class Program {static void Main (string [] args) {MyStruct a; MyStruct B;. filed = new MyClass (); B. filed = new MyClass (); Console. writeLine (. equals (B ));}}

Obviously, a and B have completely different binary bits. But the final result is:

View sourceprint? The Equals method of MyClass is called.

True

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

Misunderstanding 4: Equals is a very basic and frequently used method, so its default implementation does not have performance problems.

For the reference type, the default Implementation of Equals is very simple. You only need to determine whether the two references are of the same type and whether the two references point to the same memory. So its performance is fine. However, for the value type, Equals tasks are not that simple. It needs to compare all the fields of the two objects, that is, call the field type Equals by field. In ValueType (where the value type Equals method is implemented by default), it is impossible to know which fields are contained in all its subtypes. Therefore, to call the Equals method of the subtype field, valueType Equals requires reflection technology. As you can see, reflection is not a performance-friendly technique, so the value-type Equals method is not efficient. This is exactly why Microsoft recommends that we rewrite the Equals method for the custom value type.