Viele C#-Lehrbücher betonen das Konzept der Objektgleichheit. Wir alle wissen, dass es in der Welt von C# zwei Arten von Äquivalenz gibt. Eine davon ist die logische Äquivalenz: Wenn zwei Objekte logisch denselben Wert darstellen, spricht man von logischer Äquivalenz. Das andere ist Referenzgleichheit: Wenn zwei Referenzen auf dieselbe Objektinstanz verweisen, spricht man von Referenzgleichheit.
Wie wir alle wissen, verfügt der Objekttyp über eine Instanzmethode namens Equals, mit der ermittelt werden kann, ob zwei Objekte gleich sind. Die Standardimplementierung von Object's Equals vergleicht zwei Objekte auf Referenzgleichheit. Die von Object abgeleitete Klasse ValueTpye überschreibt die Equals-Methode, die die logische Gleichheit zweier Objekte vergleicht. Das heißt, in C# konzentriert sich die Standardversion von Equals für Referenztypen auf Referenzgleichheit, während sich Werttypen auf logische Gleichheit konzentrieren. Natürlich entspricht dies nicht immer unseren Anforderungen. Wenn uns also die logische Gleichheit von Referenztypen wichtiger ist, sollten wir die Equals-Methode überschreiben.
Ein bekanntes Beispiel für das Überschreiben der Equals-Methode eines Referenztyps, um seine Standardvergleichsmethode zu ändern, ist die String-Klasse. Wenn wir Code wie string1.Equals(string2) schreiben, vergleichen wir nicht, ob die beiden Referenzen string1 und string2 auf dieselbe Instanz verweisen (Referenzgleichheit), sondern ob die in string1 und string2 enthaltenen Zeichen identisch sind (logisch). Gleichwertigkeit).
Missverständnis 1: Die Equals-Methode und der Operator== haben das gleiche Standardverhalten.
Wenn für einen Referenztyp der ==-Operator für ihn nicht überladen ist und sein übergeordneter Typ die Equals-Methode nicht überschreibt, haben die Equals-Methode und der Operator== des Referenztyps dasselbe Standardverhalten, d. h , sie Was verglichen wird, ist die Referenzgleichheit von Objekten. Bei Werttypen ist dies jedoch überhaupt nicht der Fall! Denn wenn Sie „operator==“ für einen benutzerdefinierten Werttyp nicht überladen, können Sie keinen Code wie „myStruct1 == myStruct2“ schreiben. Andernfalls erhalten Sie einen Kompilierungsfehler, da der Werttyp keine Standardimplementierung der Überladung des Gleichheitsoperators hat.
Missverständnis 2: Die Standardimplementierung der Equals-Methode in einer benutzerdefinierten Klasse ruft automatisch die Methode „operator==“ auf, oder die Standardimplementierung der Methode „operator==“ ruft automatisch die Methode „equals“ auf.
Ich höre oft Leute sagen, dass ein bestimmter Typ ein Referenztyp ist, sodass die Standardimplementierung seiner Equals-Methode automatisch die Methode „operator==“ aufruft. Diese Aussage ist völlig unbegründet. Wie oben erwähnt, stammt die Standardimplementierung der Equals-Methode von Referenztypen von Object, während die Standardimplementierung von Werttypen von TypeValue stammt. Selbst wenn sie den ==-Operator verwenden, verwenden sie eine überladene Version von Object oder TypeValue. Solange wir die Equals-Methode einer Klasse nicht überschreiben, erbt sie im Prinzip die Implementierung ihrer übergeordneten Klasse, und die übergeordnete Klasse hat keine Möglichkeit, die Überladung von Untertypoperatoren zu verwenden. Solange wir die Equals-Methode nicht in der ==-Operatorüberladung einer Klasse aufrufen, wird sie auch nicht automatisch aufgerufen.
Missverständnis 3: Die standardmäßige Equals-Implementierung von Werttypen vergleicht zwei Objekte Stück für Stück.
Einige Leute glauben, dass die Standardimplementierung von Equals für Werttypen darin besteht, die Bitdarstellungen zweier Objekte im Speicher zu vergleichen. Das heißt, wenn alle Binärbits gleich sind, bedeutet dies, dass die beiden Objekte gleich sind. Das ist nicht korrekt. Da die Standardimplementierung von Equals für reale Werttypen darin besteht, die Equals-Methode des Feldtyps für jedes Feld des Werttyps aufzurufen, können sie nur dann gleich sein, wenn die Equals-Methode aller Felder true zurückgibt. Schauen wir uns ein Beispiel an:
class MyClass { public override bool Equals(object obj) { Console.WriteLine("MyClass的Equals方法被调用了。"); 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)); } }
Offensichtlich haben a und b völlig unterschiedliche binäre Bitdarstellungen. Aber das endgültige gedruckte Ergebnis ist:
Die Equals-Methode von MyClass wurde aufgerufen.
True
Dies zeigt, dass die Standardimplementierung von Werttypen bestimmt, ob zwei Objekte gleich sind, indem sie die Equals-Methode des Felds aufruft als durch Es wird durch Vergleich bestimmt, ob ihre Binärbits konsistent sind.
Missverständnis 4: Equals ist eine sehr einfache und häufig verwendete Methode, daher weist ihre Standardimplementierung keine Leistungsprobleme auf.
Für Referenztypen ist die Standardimplementierung von Equals sehr einfach. Sie müssen lediglich feststellen, ob zwei Referenzen vom gleichen Typ sind und ob die beiden Referenzen auf denselben Speicher verweisen. Es gibt also kein Problem mit der Leistung. Bei Werttypen ist die Aufgabe von Equals jedoch nicht so einfach. Es erfordert den Vergleich aller Felder der beiden Objekte, d. h. den Aufruf von Gleichheiten des Feldtyps Feld für Feld. Da es in ValueType (wo die Equals-Methode des Werttyps standardmäßig implementiert ist) unmöglich ist, zu wissen, welche Felder in allen seinen Untertypen enthalten sind, ist zum Aufrufen der Equals-Methode des Untertypfelds Equals von ValueType erforderlich Reflexionstechnik zu nutzen. Wie Sie vielleicht bemerkt haben, ist Reflektion keine leistungsfreundliche Technik, daher ist die Equals-Methode von Werttypen nicht effizient. Aus diesem Grund empfiehlt Microsoft, die Equals-Methode für benutzerdefinierte Werttypen zu überschreiben.
Weitere verwandte Artikel zu mehreren häufigen Missverständnissen der Equals-Methode bei C#-Anfängern finden Sie hier Achten Sie auf die chinesische PHP-Website!